Tampilkan postingan dengan label tugas gunadarma. Tampilkan semua postingan
Tampilkan postingan dengan label tugas gunadarma. Tampilkan semua postingan

Website Tutorial Adobe Ilustrator dengan PHP dan MySQL

0 komentar

Praktikum semester 8 ini ada tugas suruh buat aplikasi multimedia, didalamnya terdapat 5 unsur multimedia, yaitu suara,gambar,video,animasi dan teks. Karena bingung mau buat apa yaudah buat website tutorial adobe ilustrator aja, jadi isi websitenya ada video-video tutorial adobe ilustrator. Ini websitenya bisa diliat disini :D http://anarchy88.com/nizar

Website ini dinamis jadi ada admin yang bisa menambah, mengedit dan menghapus dan memanage website. klik linknya kalo mau liat tampilan login admin http://anarchy88.com/nizar/loginadmin.php

source codenya bisa didownload di github.

 

ini beberapa screenshotnya :D

home

 video

loginadmin

Tugas Pengantar Kecerdasan Buatan (Minggu Ke-8)

0 komentar

Pendahuluan

Script atau naskah merupakan skema representasi pengetahuan yang sama dengan frame, yaitu merepresentasikan pengetahuan berdasarkan karakteristik yang sudah dikenal sebagai pengalaman-pengalaman. Perbedaannya frame menggambarkan obyek, sedangkan script menggambarkan urutan peristiwa. Dalam menggambarkan urutan peristiwa, script menggunakan slot yang berisi informasi tentang orang, objek, dan tindakan-tindakan yang terjadi dalam suatu peristiwa.

Dalam menggambarkan urutan peristiwa, script menggunakan slot yang berisi informasi tentang orang, obyek, dan tindakan-tindakan yang terjadi dalam suatu peristiwa. Elemen-elemen script meliputi:

1. Kondisi input, yaitu kondisi yang harus dipenuhi sebelum terjadi atau berlaku suatu peristiwa dalam script.
2. Track, yaitu variasi yang mungkin terjadi dalam suatu script.
3. Prop, berisi obyek-obyek pendukung yang digunakan selama peristiwa terjadi.
4. Role, yaitu peran yang dimainkan oleh seseorang dalam peristiwa.
5. Scene, yaitu adegan yang dimainkan yang menjadi bagian dari suatu peristiwa.
6. Hasil, yaitu kondisi yang ada setelah urutan peristiwa dalam script terjadi.

Berikut elemen script :

1. jalur/track, yaitu variasi yang mungkin terjadi dalam suatu script
2. role/peran, yaitu peran yang dimainkan oleh seseorang dalam peristiwa
3. property, berisi objek-objek pendukung yang digunakan selama peristiwa terjadi
4. kondisi input, yaitu kondisi yang harus dipenuhi sebelum terjadi atau berlaku suatu peristiwa dalam script
5. scene, yaitu adegan yang dimainkan yang menjadi bagian dari suatu peristiwa
6. hasil, yaitu kondisi yang ada setelah urutan peristiwa dalam script terjadi.

Dan ini merupakan tugas pengantar kecerdasan buatan

Soal :

Buat naskah / script yang terdiri dari :

  1. Jalur / track
  2. Role (pemerannya)
  3. Properti (pendukung)
  4. Kondisi input
  5. Adegan / scene ( min 5 adegan max 10) : masing-masing adegan diperinci
  6. Hasil

Jawaban :

Pada tugas pengantar kecerdasan buatan minggu ke-8 ini, saya akan membuat script kejadian ketika kita mengikuti “Sidang Skripsi”.

Jalur (track) : Sidang Skripsi
Role (peran) : mahasiswa, dosen penguji
Property (pendukung) : soft cover penulisan, transparansi, lembar absensi, lembar hasil sidang, dll
Kondisi Input : mahasiswa yang penulisannya sudah disetujui oleh dosen pembimbing dan sudah terdaftar sebagai peserta sidang.

Adegan/scene ke-1 : Persiapan sidang
- Mahasiswa mendatangi ruang sidang.
- Dosen penguji mendatangi ruang sidang.
- Dosen penguji memberikan lembar absensi kepada mahasiswa.
- Mahasiswa mengisi lembar absensi.
- Mahasiswa memberikan lembar absensi ke dosen penguji.
- Mahasiswa menunggu giliran untuk di panggil sidang.

Adegan/scene ke-2 : Mahasiswa masuk ke ruang sidang
- Dosen penguji memanggil nama mahasiswa.
- Mahasiswa memasuki ruang sidang.
- Mahasiswa mempersiapkan transparansi.
- Mahasiswa memberikan soft cover penulisan kepada dosen penguji.

Adegan/scene ke-3 : Mahasiswa melakukan presentasi
- Mahasiswa mempresentasikan tentang penulisannya.
- Dosen penguji membaca penulisan mahasiswa.
- Dosen penguji bertanya tentang penulisan mahasiswa.
- Mahasiswa menjawab pertanyaan dosen penguji.

Adegan/scene ke-4 : Mahasiswa selesai sidang
- Dosen penguji menulis ada/tidaknya revisi di lembar hasil sidang.
- Mahasiswa membereskan transparansi.
- Dosen penguji memberikan lembar hasil sidang ke mahasiswa.

Adegan/scene ke-5 : Mahasiswa keluar dari ruang sidang
- Dosen penguji mempersilahkan mahasiswa keluar ruangan.
- Mahasiswa membawa kembali transparansi, soft cover penulisan dan lembar hasil sidang.
- Mahasiswa keluar ruangan.

Hasil
- Mahasiswa merasa senang.
- Mahasiswa merasa lega.
- Mahasiswa merasa bangga.
- Mahasiswa bersyukur.
- Mahasiswa kecewa.
- Mahasiswa pusing.

Subject, Verb, Complement , and Modifier

0 komentar

Tugas Bahasa Inggris Bisnis 2

1. Goerge is cooking dinner tonight
Subject / verb / c / modifier time

2. Henry and Marcia have visited the president
Subject / verb / complement

3. We can eat lunch in this restaurant today.
S / v / c / m place & time

4. Pat should have bought gasoline yesterday
S / v / c / m

5. Trees grow
S / v

6. It was raining at seven o’clock this morning
s / v / m

7. She opened a checking account at the bank last week
S / v / c / m.place & time

8. Harry is washing dishes right now.
S / v / c / m

9. She opened her book
S / v / c

10. Paul, William, and Marry were watching television a few minutes ago
S / v / c / m

JARINGAN SEMATIK (TUGAS PKB MINGGU KE-7)

0 komentar

Jaringan Semantik, kalimatnya sebagai berikut :

- Contoh Alat Elektronik adalah Handphone
- Handphone mempunyai merk Nokia dan Motorolla
- CDMA dan GSM merupakan jenis dari Nokia dan Motorolla
- Seri E, Express Music, fold, Z series merupakan type GSM
- Seri E memiliki tipe E63, dan E 71.
- Express Music memiliki tipe 5800
- Fold memiliki tipe 6600
- Z series memiliki tipe Z 6
- E 63 dan E 71 berbentuk candy bar
- Z6 dan 5800 berbentuk Slide
- 6600 berbentuk berbentuk flip
- 1265 dan 6316 adalah tipe dari CDMA
- 1265 berbentuk candy bar
- 6316 berbentuk slide

klik gambar untuk memperjelas :D

anu

TUGAS PENGANTAR KECERDASAN BUATAN MINGGU KE 6

0 komentar

SOAL

1. Representasikan fakta berikut menggunakan logika predikat dan logika proposisi !

  • Karjo adalah seorang laki-laki
  • Karjo adalah orang jawa
  • Karjo lahir tahun 1840
  • Setiap laki-laki pasti akan mati
  • Semua orang jawa mati pada saat krakatau meletus tahun 1883
  • Setiap orang pasti mati setelah hidup lebih dari 150 tahun
  • Sekarang tahun 2010
  • Mati berarti tidak hidup
  • Jika seseorang mati maka beberapa waktu kemudian dia pasti dinyatakan telah mati

2. Buktikan bahwa Karjo masih hidup atau mati saat ini !

 

JAWABAN :

1.) Merepresentasikan pengetahuan / fakta dengan menggunakan logika proposisi dan predikat

a. Karjo adalah seorang laki-laki

Jawab : laki-laki ( Karjo)

b. Karjo adalah orang jawa

Jawab : orang jawa ( Karjo)

c. Karjo lahir tahun 1840

Jawab : lahir ( Karjo, tahun 1840)

d. Setiap laki-laki pasti akan mati

Jawab : "x : laki-laki (x) –> mati (x)

e. Semua orang jawa mati pada saat Krakatau meletus tahun 1883

Jawab : "x: orang jawa(x) L meletus (Krakatau, tahun 1883) –>  mati (x)

f. Setiap orang pasti mati setelah hidup lebih dari 150 tahun

Jawab : "x: orang (x) L hidup ( >y) –>  mati (x)

g. Sekarang tahun 2010

Jawab : tahun (2010, sekarang)

h. Mati berarti tidak hidup

Jawab : Ø hidup (x) –>  mati (x)

i. Jika seseorang mati maka beberapa waktu kemudian dia pasti dinyatakan telah mati

Jawab : "x: orang(x) L waktu (y) –>  mati(x)

 

2.) Membuktikan bahwa Karjo telah mati

- Karjo lahir tahun 1840

- Sekarang tahun 2010

- Setiap orang pasti mati setelah hidup lebih dari 150 tahun

Kesimpulan : Karjo telah mati pada tahun 2010 karena telah hidup lebih dari 150 tahun

Jawab : "x: tahun (y,x) L hidup (>z) –>  mati(x)

- Karjo orang jawa

- Karjo lahir tahun 1840

- Setiap orang jawa mati pada saat Krakatau meletus tahun 1883

Kesimpulan : Karjo yang orang jawa pasti mati pada saat Krakatau meletus tahun 1883

Jawab : "x: orang jawa(x) L meletus (y,z) –>  mati(x)

Remote Procedure Call (RPC)

2 komentar

Remote Procedure Call (RPC) adalah sebuah metode yang memungkinkan kita untuk mengakses sebuah prosedur yang berada di komputer lain. Untuk dapat melakukan ini sebuah server harus menyediakan layanan remote procedure. Pendekatan yang dilakuan adalah sebuah server membuka socket, lalu menunggu client yang meminta prosedur yang disediakan oleh server. Bila client tidak tahu harus menghubungi port yang mana, client bisa me- request kepada sebuah matchmaker pada sebuah RPC port yang tetap. Matchmaker akan memberikan port apa yang digunakan oleh prosedur yang diminta client.

RPC masih menggunakan cara primitif dalam pemrograman, yaitu menggunakan paradigma procedural programming. Hal itu membuat kita sulit ketika menyediakan banyak remote procedure. RPC menggunakan socket untuk berkomunikasi dengan proses lainnya. Pada sistem seperti SUN, RPC secara default sudah ter- install kedalam sistemnya, biasanya RPC ini digunakan untuk administrasi sistem. Sehingga seorang administrator jaringan dapat mengakses sistemnya dan mengelola sistemnya dari mana saja, selama sistemnya terhubung ke jaringan.

Umumnya protokol RPC yang digunakan pada saat ini adalah DCOM (Distributed Component Object Model). Saat ini ada alternatif protokol baru, yakni SOAP (Simple Object Access Protocol), yang berdasarkan pada teknologi XML.

Implementasi RPC

Sun Microsystems Open Network Computing (ONC) : RPC specification, XDR (eXternal Data Representation) standard, UDP atau TCP transport protocol.

Xerox Courier : RPC model, Data representation standard, XNS (Xerox Network Systems) SPP (Sequenced Packet Protocol) sebagai transport protocol, Apollo’s Network Computing Architecture (NCA), RPC protocol, NDR (Network Data Representation).

Kelebihan RPC

· Relatif mudah digunakan

Pemanggilan remote procedure tidak jauh berbeda dibandingkan pemanggilan local procedure. Sehingga pemrogram dapat berkonsentrasi pada software logic, tidak perlu memikirkan low level details seperti soket, marshalling & unmarshalling.

· Robust (Sempurna)

Sejak th 1980-an RPC telah banyak digunakan dlm pengembangan mission-critical application yg memerlukan scalability, fault tolerance, & reliability.

Kekurangan RPC

· Tidak fleksibel terhadap perubahan

- Static relationship between client & server at run-time.

- Berdasarkan prosedural/structured programming yang sudah ketinggalan jaman dibandingkan OOP.

· Kurangnya location transparency

- Misalnya premrogram hanya boleh melakukan pass by value, bukan pass by reference.

- Komunikasi hanya antara 1 klien & 1 server (one-to-one at a time).

- Komunikasi antara 1 klien & beberapa server memerlukan beberapa koneksi yg terpisah.

Prinsip RPC dalam program clien-server

untitled

Langkah-langkah dalam RPC

untitled1

1. Client procedure memanggil client stub secara normal

2. Client stub membuat pesan, memanggil local OS

3. Clients OS mengirim pesan ke remote OS

4. Remote OS member pesan ke server stub

5. Server stub membuka parameters, memanggil server

6. Server bekerja, mengembalikan hasil ke stub

7. Server stub mengepak itu kedalam pesan, memanggil local OS

8. Server OS mengirim pesan ke client OS

9. Client OS member pesan client stub

10. Stub membuka hasil, mengembalikan ke client

 

Contoh Implementasi RPC dengan SUN RPC

· Fungsi yg dipanggil client melalui RPC:

- bin_date_1:

No arguments.

Result in long integer: waktu saat ini, dlm jumlah detik sejak 00:00:00 GMT, January 1, 1970.

- str_date_1

Mengkonversi hasil bin_date_1 menjadi readable ASCII sring.

· Berkas yg dibuat programmer:

- Server procedure: date_proc.c

- RPC specification file: date.x

- Client main function: rdate.c

· date.x -> rpcgen ->

- Server stub: date_svc.c

- date.h

- Client stub: date_clnt.c

· Generate executable client program:

- cc o rdate rdate.c date_clnt.c lrpclib

· Generate executable server program:

- cc o date_svc date_proc.c date_svc.c lrpclib

 

http://bebas.vlsm.org/v06/Kuliah/SistemOperasi/BUKU/SistemOperasi-4.X-1/ch17s06.html

http://viyan.staff.gunadarma.ac.id/Downloads/files/11848/2_Komunikasi.pdf

Masalah Desain dalam Sistem Terdistribusi

1 komentar

Banyak proyek rekayasa perangkat lunak melibatkan otomatisasi dari "dunia nyata" sistem, yang terdiri dari interaksi entitas yang bekerja sama untuk melaksanakan tugas-tugas tertentu. Ini sistem dunia nyata sering menunjukkan kualitas intrinsik yang sejajar karakteristik yang melekat pada sistem distribusi perangkat lunak.

Salah satu kualitasnya ialah persetujuan . Sebuah sistem dunia nyata memiliki kualitas ini jika itu mencakup lebih dari satu entitas pada setiap saat, yang paling lakukan. Sebagai contoh, pertimbangkan sebuah sistem untuk paket pengiriman paket di seluruh dunia. Pada setiap waktu, sistem ini dapat mencakup banyak entitas fisik (misalnya, paket, pelanggan, dan lokasi) dan konsep-konsep abstrak (misalnya, tingkat, asal-usul, dan tujuan.) Masing-masing dapat berdiri sendiri dan perilaku secara bersamaan. Sistem distribusi perangkat lunak memberikan informasi persetujuan dengan menyalurkan objek melalui jaringan sumber daya komputasi. Sebaliknya, terpusat (single-prosesor) sistem hanya dapat mensimulasikan persetujuan.

Dalam sistem dunia nyata, satu kesatuan, seperti sebuah paket atau pelanggan, bisa gagal independen dari sisa sistem. Hal yang sama berlaku untuk sistem terdistribusi karena individu sumber daya komputasi dalam jaringan dapat gagal atau menjadi tidak terjangkau. Dalam sistem terpusat, kegagalan biasanya diperlakukan sebagai semua-atau-kondisi apa-apa.

Kualitas umum ketiga adalah dinamis, perubahan yang meningkat. Sistem dunia nyata jarang memerlukan shutdown yang lengkap untuk membuat perubahan dalam cara bahwa pekerjaan dilakukan. Bahkan, perubahan sering dianggap sebagai bagian integral dari sistem dunia nyata dan bukan proses eksternal. Dapatkah Anda gambar perusahaan perkapalan di seluruh dunia menghentikan seluruh operasi setiap kali sebuah kantor yang diperlukan untuk menambah peralatan baru atau membuka saluran distribusi baru? Situasi yang sama ada untuk sistem terdistribusi. Karena ketidakpraktisannya dari mematikan seluruh sistem terdistribusi, mekanisme untuk dinamis dan perubahan yang meningkat sering dibangun ke dalam infrastruktur.

Kemiripan antara dunia nyata dan sistem terdistribusi perangkat lunak, mungkin membawa kita untuk menyimpulkan bahwa model konseptual yang akurat yang pertama dapat dengan mudah berubah menjadi desain yang baik untuk saluran kedua. Namun, hal ini tidak benar karena beberapa halus dan tidak begitu-perbedaan halus dalam apa yang model mewakili dan karena masalah desain tambahan yang berkaitan dengan sistem terdistribusi. Secara umum, proses pergi dari analisis ke desain dalam pengembangan perangkat lunak selalu terlibat pemetaan atau transformasi model konseptual. Model yang digunakan selama analisis, terlepas dari apakah mereka formal atau informal, bertujuan untuk menjelaskan sistem dunia nyata dari masalah-domain perspektif. Konsep yang ditemukan dalam sebuah model analisis harus berhubungan langsung dengan konsep-konsep dalam sistem dunia nyata. Model perangkat lunak yang digunakan untuk desain, di sisi lain, melibatkan tingkat tambahan abstraksi dan melayani tujuan yang berbeda. Mereka menjelaskan konsep perangkat lunak, seperti objek, struktur, dan proses, yang hanya secara tidak langsung berhubungan dengan konsep-konsep dari masalah-domain. Tujuan dari desain model adalah untuk menyediakan cetak biru untuk implementasi dan kerangka kerja untuk evolusi berikutnya dari sistem. Idealnya, jarak konseptual antara analisis dan desain yang sesuai harus disimpan ke minimum.

Persyaratan untuk model konseptual yang lebih baik

Meskipun beberapa masalah di atas adalah karena alat-alat pengembangan yang tidak memadai untuk sistem terdistribusi, tidak mungkin lebih baik, lebih banyak peralatan canggih akan membuat perbedaan. Pada kenyataannya, mereka mungkin bahkan membuat masalah semakin buruk. Penggunaan yang tidak tepat alat baru sengaja dapat meningkatkan komunikasi dan sumber daya yang muncul berbagi, dan dengan demikian, lebih rumit desain. Sebuah sepenuhnya terintegrasi dan meminimalkan koleksi alat pembangunan secara substansial dapat mengurangi kompleksitas desain sistem terdistribusi. Namun, dalam pasar terbuka dengan berbagai keragaman platform dan dengan infus konstan teknologi baru, seperti lingkungan pengembangan tidak realistis. Harapan terbaik kita adalah untuk memperbaiki model konseptual sistem perangkat lunak didistribusikan. Abstraksi yang diusulkan ini harus memberikan software engineer kontrol atas keputusan desain, tapi memungkinkan mereka untuk menyembunyikan rincian ketika mereka tidak berhubungan dengan diskusi tertentu.

Kesimpulan

Dengan menambahkan abstraksi yang sesuai untuk model kita, kita juga bisa mengurangi jarak antara analisis konseptual dan desain.

Sumber : http://osm7.cs.byu.edu/ER97/workshop4/sc.html