BAB II LANDASAN TEORI

2.1

Lightweight Directory Access Protocol (LDAP) LDAP merupakan kependekan dari Lightweight Directory Access Protocol

adalah suatu aplikasi dan protokol untuk query dan memodifikasi layanan direktori yang berjalan pada protokol TCP/IP. Sebuh direktori adalah suatu set objek dengan atribut yang diselenggarakan dengan cara logis dan hierarkis. Sebuah contoh sederhana adalah direktori telepon, yang terdiri dari daftar namanama (baik nama orang atau organisasi) yang disusun menurut abjad, dengan nama masing-masing memiliki alamat dan nomor telepon yang terkait dengan nya. Pohon direktori LDAP berisi daftar politik, geografis, dan/atau batas-batas organisasi, tergantung pada model yang dipilih. Penerapan LDAP pada saat ini cenderung menggunakan Domain Name System (DNS) untuk struktur di tingkat paling atas dari hierarki. Versi terakhir dari LDAP adalah LDAPv3 yang ditentukan oleh Internet Engineering Task Force (IETF) sebagai RFC4510. Menurut Carter (2003), pengertian LDAP dibagi menjadi 3 bagian, yaitu : 1. 2. 3. Lightweight Directory Access Protocol

2.1.1

Lighweight LDAP dikatakan ringan jika dibandingkan dengan X.500 servis direktori (Carter, 2003). Hal ini dikarenakan pada mulanya root LDAP sangat dekat terkait dengan X.500. LDAP pada mulanya dibuat sebagai protokol desktop yang lebih muda yang digunakan sebagai gateway untuk X.500 server. X.500 merupakan sebuah standard. X.500 mendapatkan gelar Heavyweight karena membutuhkan client dan server untuk berkomunikasi menggunakan Open System Interface (OSI) protokol. Tujuh layer OSI ini bagus dalam mengaplikasikan jaringan protokol suite, tetapi ketika dibandingkan dengan TCP/IP protokol suite, ini serupa dengan bepergian jauh dengan dengan barang bawaan yang sangat berat. Dengan demikian LDAP dikatakan ringan (lightweight) karena menggunakan pesan sedikit diatas udara yang dipetakan secara langsung pada TCP layer (biasanya port 389) dari TCP/IP protokol (Carter, 2003). Karena X.500 merupakan layer aplikasi protokol (dalam OSI layer) maka ini akan membawa lebih banyak bawaan, seperti network header yang dipasang pada paket pada setiap layer sebelum akhirnya dikirimkan ke jaringan.

10

Gambar 2.1 X.500 dengan OSI Vs LDAP dengan TCP/IP

LDAP

juga

dikatakan

ringan

(lightweight),

karena

menghilangkan banyak operasi X.500 yang jarang digunakan (Carter, 2003). LDAPv3 hanya memiliki sembilan operasi utama dan menyediakan model sederhana untuk programmer dan administrator. Menyediakan satu set operasi yang lebih kecil dan sederhana yang mengijinkan pengembang untuk fokus pada seluk-beluk dari program tanpa harus mengerti keunggulan dari protokol yang jarang digunakan. Dengan jalan ini pembuat LDAP berharap untuk meningkatkan penggunaan dengan menyediakan pengembangan aplikasi yang lebih mudah.

2.1.2

Directory Jaringan servis direktori bukanlah suatu hal yang baru, khususnya untuk Domain Name System (DNS) (Carter, 2003). Bagaimanapun servis direktori sering dibingungkan dengan database. Perlu diingat bahwa servis direktori dan database memiliki karakteristik masing-masing, seperti

11

pencarian cepat dan schema yang dapat diperluas. Perbedaannya adalah direktori dibuat untuk dibaca lebih banyak dari pada ditulis. Sedangkan untuk database diasumsikan untuk operasi baca dan tulis memiliki frekuensi yang sama. Asumsi bahwa direktori dibaca lebih sering dari pada ditulis merupakan suatu keunggulan yang spesifik untuk sebuah database, seperti dukungan untuk transaksi dan menulis lock merupakan sesuatu hal yang tidak penting untuk servis direktori seperti LDAP. Pada titik ini penting untuk membedakan antara LDAP dengan backend yang digunakan untuk menyimpan data. Ingat bahwa LDAP hanya sebuah protokol, yang penting adalah LDAP adalah sebuah set dari pesan yang digunakan untuk mengakses data yang spesifik. Protokol ini tidak mengatakan apapun tentang dimana data disimpan. Pada intinya adalah bahwa client tidak akan (dan tidak akan pernah) melihat atau bahkan tahu tentang mekanisme penyimpanan backend (Carter, 2003).

Gambar 2.2 Hubungan antara LDAP Client, Server, dan Data Storage

Seperti sudah disarankan bahwa LDAP server dapat digunakan sebagai backend storage untuk web server. Semua HTML dan file grafik dapat disimpan dalam direktori dan dapat dipertanyakan (query) oleh

12

banyak web server. Disamping semuanya, sebuah web server biasanya hanya membaca file dan mengirimkannya ke client, file itu sendiri tidak akan sering diubah. Ketika ini mungkin untuk mengimplementasikan web server yang menggunakan LDAP untuk mengakses backend storage, ada sebuah tipe spesial dari direktori yang telah ada, dan ini merupakan suite yang lebih baik untuk memenuhi kebutuhan melayani file, namanya adalah filesystem. Dengan demikian ada dua inti penting yang dapat diambil tentang maksud fungsi dari LDAP (Carter, 2003) : 1. LDAP tidak secara umum menggantikan special direktori seperti halnya filesystem atau DNS. 2. Ketika menyimpan suatu tipe spesifik dari informasi binary (misal : jpeg foto) dalam direktori dapat digunakan, LDAP tidak dimaksudkan untuk menyimpan tipe tertentu seperti blobs (Binary Lumps of Bits).

2.1.3

Access Protocol Penjelasan berikut akan cukup untuk membuat berpikir bahwa LDAP merupakan message-based, client/server protokol yang

didefinisikan dalam RFC 2251. LDAP itu asynchronous (meskipun banyak peralatan development menyediakan baik blocking dan

nonblocking API), ini berarti bahwa sebuah client dapat menimbulkan banyaknya permintaan dan responsnya mungkin datang dalam urutan yang berbeda ketika permintaan itu dimunculkan (Carter, 2003).

13

Gambar 2.3 LDAP Request dan Response

2.1.4

Struktur Direktori LDAP Struktur direktori LDAP mengikuti struktur direktori dari X.500 edisi 1993. Isi direktori jika direpresentasikan dengan format LDIF terlihat seperti di bawah ini. # Barbara's Entry dn: cn=Barbara J Jensen,dc=example,dc=com cn: Barbara J Jensen cn: Babs Jensen objectClass: person sn: Jensen # Bjorn's Entry dn: cn=Bjorn J Jensen,dc=example,dc=com cn: Bjorn J Jensen cn: Bjorn Jensen objectClass: person sn: Jensen # Base64 encoded JPEG photo jpegPhoto:: /9j/4AAQSkZJRgABAAAAAQABAAD/2wBDABALD A4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQ ERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVG # Jennifer's Entry dn: cn=Jennifer J Jensen,dc=example,dc=com

14

cn: Jennifer J Jensen cn: Jennifer Jensen objectClass: person sn: Jensen # JPEG photo from file jpegPhoto:< file:///path/to/file.jpeg

Dimana dn merupakan nama dari kumpulan data diatas, cn adalah common name, sn adalah surname, dc adalah domain component. Berikut merupakan tabel untuk singkatan yang biasa di gunakan dalam LDAP : Tabel 2.1 Daftar Singkatan pada LDAP Singkatan dn o ou dc cn sn uid c l st gn mail Keterangan distinguished name organization organization unit domain components common name surname user id country name locality name state given name e-mail address

2.1.5

Operasi LDAP Client mengirimkan permintaan ke server berupa ID pesan dan server merespon dengan ID yang sama. Respon dapat termasuk kode-kode numerik yang dapat diartikan sebagai query sukses, error ataupun pesanpesan lainnya. Proses lengkap dari operasi LDAP ini adalah : 1. 2. 3. Pengertian TLS Bind (Otentikasi) Mencari dan mencocokan data

15

4.

Unbind

2.1.5.1 Pengertian TLS TLS (Transport Layer Security) merupakan turunan SSL (Security Socket Layer) dapat digunakan untuk melindungi data dari kemungkinan proses penyadapan. Pada saat proses negosiasi, server mengirimkan sertifikat X.509 untuk membuktikan identitasnya, begitu juga client. Setelah identitas masing-masing diketahui, client dapt menggunakan SASL untuk mengotentikasi dirinya. Server juga dapat menyediakan layanan LDAPS yang tidak standar dengan menggunakan SSL. Layanan ini menggunakan port berbeda, biasanya pada port 636. Layanan ini mulai ditinggalkan pada LDAPv3 dan hanya digunakan pada LDAPv2.

2.1.5.2 Bind (Otentikasi) Operasi bind akan mengotentikasikan client ke server penyedia layanan. Proses bind sederhana mengirimkan DN dan password dalam kondisi plain text sehingga diperlukan TLS untuk melindungi koneksi dari kemungkinan penyadapan. Pada LDAPv2, bind merupakan operasi pertama yang harus dilakukan sebelum melakukan operasi-operasi selanjutnya, hal ini tidak diperlukan lagi pada LDAPv3.

16

2.1.5.3 Mencari dan Mencocokan Data Operasi ini bertujuan untuk mencari data dan membaca data pada direktori sesuai dengan permintaan pemakai. Parameter dari operasi ini adalah : baseObject scope : DN (Distinguished Name) dari isi yang akan dicari : Elemen yang akan dicari pada struktur direktori dibawah

baseObject. Bisa berupa baseObject (nama, alamat), singleLevel (satu data tepat dibawah baseObject), atau wholeSubstree (semua data yang ada pada DN)

2.1.5.4 Unbind Operasi unbind berfungsi untuk meninggalkan semua operasi dan menutup koneksi ke server penyedia layanan LDAP. Operasi ini tidak memiliki respon. User dapat membatalkan sesi dengan hanya menutup koneksi, akan tetapi untuk lebih aman user harus melakukan operasi unbind jika akan meninggalkan sesi. Unbind akan memberikan kesempatan kepada server untuk menutup koneksi dengan sempurna, mengurangi

kemungkinan sesi dapat dipakai oleh user lainnya, membebaskan resource yang dipakai oleh koneksi dan juga memerintahkan server untuk membatalkan operasi yang bisa dibatalkan dan tidak akan mengirimkan respon untuk operasi yang tidak dapat dibatalkan.

17

2.1.6

Model LDAP Model LDAP mewakili servis yang disediakan oleh server, seperti yang dilihat oleh client. Model ini merupakan model abstrak yang menjelaskan tentang berbagai macam aspek dari direktori LDAP (Carter, 2003). RFC 2251 membagi direktori LDAP menjadi dua komponen, yaitu protokol model dan data model. Ada empat model yang didefinisikan oleh Timothy A. Howes, dkk (Howes et al, 2003): 1. Information Model Model informasi menyediakan struktur dan tipe data yang diperlukan untuk membangun sebuah pohon direktori LDAP. Inputannya adalah unit dasar dari sebuah direktori LDAP. Bentuk visualnya dapat dilihat sebagai node interior atau node exterior dalam Directory Information Tree (DIT). Sebuah inputan terdiri dari informasi tentang misalnya satu atau lebih objectClasses. ObjectClasses ini memiliki kebutuhan yang spesifik atau atribut pilihan. Tipe atribut harus dibuat encoding dan aturan pencocokannya yang menentukan sesuatu sebagai tipe dari data atribut dapat ditahan dan bagaimana membandingkan data ini selama melakukan pencarian.

2. Naming Model Model naming menentukan bagaimana entry dan data dalam DIT memiliki alamat yang unik. Setiap entry memiliki sebuah atribut yang unik diantara semua atribut yang lain. Keunikan atribut ini dinamakan

18

Relative Distinguished Name (RDN). Keunikan suatu atribut dapat dicari dengan mengenali entry dalam sebuah direktori dengan mengikuti RDN dari semua entry dalam jalur dari node yang diinginkan sampai root dari tree. String ini dibuat dengan mengkombinasikan RDN ke dalam bentuk nama yang unik yang disebut node Distinguished Name (DN).

Gambar 2.4 Contoh Tree Directory LDAP

Garis besar entry direktori pada gambar diatas mempunyai sebuah RDN yaitu cn=gerald carter. Sebagai catatan bahwa nama atribut akan sama dengan nilai yang dimasukkan dalam RDN. DN untuk node ini akan menjadi cn=gerald carter, ou=people, dc=plainjoe, dc=org.

3. Fungsional Model Model fungsional adalah protokol LDAP itu sendiri. Protokol ini menyediakan tujuan untuk mengakses data dalam tree direktori. Akses

19

diimplementasikan dengan operasi otentikasi (binding), operasi query (search dan read), dan operasi update (write).

4. Security Model Model security menyediakan sebuah mekanisme untuk client yang digunakan untuk membuktikan identitas (authentication) dan untuk server adalah sebagai pengatur client yang terautentifikasi dalam mengakses data (authorization). LDAPv3 menyediakan beberapa metode autentifikasi yang tidak didapatkan dalam protokol versi sebelumnya. Beberapa keunggulan, seperti access control list, belum mendapat standarisasi, sehinggal membiarkan vendor dengan

perlengkapan mereka sendiri.

Pada level tingkat tinggi ini, LDAP termasuk kategori sederhana. LDAP adalah sebuah protokol untuk membangun pembagian direktori tingkat tinggi.

2.1.7

LDAP Schema Menurut Arkills (2003), schema menentukan aturan yang menguasai sebagian besar dari apa yang direktori LDAP dapat lakukan. Schema menentukan jenis apa dari entry yang dapat dibuat dalam direktori. Ini menentukan informasi apa yang dapat disimpan. Jadi

20

pengubahan schema dapat meningkatkan lebih besar nilai dari direktori LDAP dan fleksibilitasnya. Pengubahan schema untuk mengijinkan sebuah tipe baru dari objek atau sebuah tipe atribut baru. Ini berdampak pada pembuatan tipe bari dari sebuah entry yang dapat ditambah lebih banyak pada fungsi dari direktori itu sendiri. Schema terdiri dari beberapa komponen. Pada gambar di bawah ini ditunjukkan bagaimana setiap elemen dari schema berhubungan dalam konteks dari schema.

Gambar 2.5 Diagram Konseptual dari Schema

2.1.8

Directory Management Menurut Arkills (2003), menggabungkan informasi ke dalam sebuah direktori adalah alasan utama dari pengimplementasian LDAP. Kontrol administratif mengijinkan administrator sebuah direktori untuk

21

lebih mudah mengatur direktori LDAP yang oleh karena itu berhubungan dengan nilai bisnis yang disediakan oleh LDAP.

2.1.9

Directory Security Menurut Arkills (2003), Autentication adalah sebuah proses yang menyatakan dan menegaskan siapa sebenarnya user, dengan kata lain ini membangun identitas dari client. Secara praktek identitas ini biasanya adalah sebuah username, user identity (uid), tiket, atau sertifikat. Menurut Arkills (2003), Authorization adalah sebuah proses pembangunan dimana sebuah client diotorisasi untuk mengakses resource. Proses ini dapat ditentukan dengan kombinasi dari faktor access control seperti authentication identity, source IP, kekuatan enkripsi, metode autentikasi, operasi request, dan sumber request. Tabel 2.2 Tipe Aturan Akses Direktori

Certificate memetakan sebuah public key pada sebuah identitas. Sedangkan sebuah Certificate Authority (CA) adalah wewenang dari

22

bagian lain yang dapat dipercaya. Sebagai contoh agar lebih jelas dapat dilihat pada gambar di bawah ini.

Gambar 2.6 CA dengan Certificate

Secure Socket Layer (SSL) menggabungkan enkripsi public dan secret key. SSL juga dapat digunakan untuk mengenkripsi sebuah servis session antara banya dua bagian. Transport Layer Security (TLS) merupakan turunan dari SSL. TLS juga merupakan sebuah standar untuk internet, hal ini didefinisikan dalam RFC 2246.

23

2.2

Central Authentification Service (CAS) Central Authentication Service (CAS) merupakan sebuah sistem otentikasi

yang aslinya dibuat oleh Universitas Yale untuk menyediakan sebuah jalan yang aman untuk sebuah aplikasi untuk mengotentikasi user. CAS kemudian diimplementasi sebagai sebuah open source komponen server Java dan mendukung library dari client untuk Java, PHP, Perl, Apache, uPortal, dan lainnya. CAS server sebagai sebuah dasar untuk beberapa framework untuk keamanan dan solusi Single Sign On (Kristian Aaslund et al, 2007). CAS terdiri dari kumpulan java servlet dan dapat berjalan pada hampir semua servlet engine (JSP spec 1.2. compliant) yang menawarkan layanan otentikasi berbasis web. Kelebihan dari CAS adalah keamanan, fitur proxying, fleksibilitas, ketahanan dan pustaka client yang bermacam-macam. Gambar 2.7 menggambarkan proses otentikasi dan perjalanan user dan password pada aplikasi tanpa CAS dan aplikasi terintegrasi dengan CAS. Pada aplikasi tanpa CAS proses otentikasi terjadi pada masing-masing aplikasi dan tiap aplikasi mengakses database user dimana proses ini sangat rawan terhadap penyadapan data login. Sedangkan pada aplikasi dengan CAS proses otentikasi dan pengaksesan database user hanya berjalan pada server otentikasi. Aplikasi memanfaatkan tiket yang dihasilkan server otentikasi untuk melakukan otentikasi terhadap user.

24

Gambar 2.7 Perbandingan Penggunaan CAS

Kelebihan-kelebihan yang terpasang pada CAS antara lain : 1. Keamanan

Keamanan diimplementasikan dengan cara : a. Password hanya dikirim dari browser ke server otentikasi dimana proses pengiriman selalu melewati jalur yang terenkripsi. b. Otentikasi ulang tidak terlihat pada sisi user, yang memastikan bahwa cookie yang diterima adalah cookie yang unik, cookie ini disebut Ticket Granting Cookie. Cookie ini tidak mengandung informasi pribadi dari user yang melakukan proses otentikasi, terlindungi dengan protokol HTTPS dan hanya dapat dibaca oleh server otentikasi c. Tiket yang telah dikeluarkan oleh server otentikasi dikirim ke aplikasi yang meminta otentikasi melalui web browser dan akhirnya divalidasi oleh server

25

otentikasi, sehingga dengan mekanisme ini aplikasi tidak pernah meminta data nama user dan password kepada user aplikasi tersebut. 2. Otentikasi Proxy Mekanisme Single Sign On klasik tergantung pada komunikasi antara browser dan aplikasi yang menyebabkan installasi multitier tidak bisa dijalankan pada aplikasi yang membutuhkan layanan backend untuk otentikasi. CAS Versi 2.0 dapat mengatasi masalah ini dengan menawarkan cara yang lebih baik untuk otentikasi. Dengan proxy granting ticket dan proxy ticket yang mengijinkan aplikasi pihak ketiga untuk mendapatkan otentikasi. Fitur ini merupakan kelebihan yang utama pada CAS. 3. Fleksibilitas Paket yang ditawarkan oleh pengembang CAS adalah implementasi lengkap dari protokol otentikasi, akan tetapi otentikasi itu sendiri (pengelolaan database user dll) harus dilakukan oleh administrator.

Pustaka Client Kode dari protokol dasar dapat dengan mudah ditulis pada sisi klien. Pustaka tambahan tersedia untuk bahasa Perl, Java, ASP, PHP, dan PL/SQL. Semua pustaka tersebut memberikan fleksibilitas yang baik untuk memasukkan CAS pada suatu aplikasi hanya dengan menambahkan beberapa baris code.

26

2.3

Konsep Dasar Single Sign On (SSO) Single Sign On (SSO) adalah teknologi yang mengizinkan pengguna

jaringan agar dapat mengakses sumber daya dalam jaringan hanya dengan menggunakan satu acccount user saja (once register multiple access). Teknologi ini sangat diminati, khususnya dalam jaringan yang sangat besar dan bersifat heterogen. Dengan menggunakan SSO, seorang pengguna hanya cukup melakukan proses otentikasi sekali saja untuk mendapatkan izin akses terhadap semua layanan yang terdapat di dalam jaringan. Contoh dari sistem SSO adalah protokol Kerberos, yang telah dimasukkan ke dalam sistem operasi Windows 2000 ke atas. Protokol yang sama dapat juga digunakan di dalam keluarga sistem operasi UNIX. Novell juga telah menawarkan fungsi SSO miliknya sendiri, yang disebut sebagai Novell Single Sign On (NSSO) yang dapat digunakan dalam lingkungan Windows/NetWare. Beberapa

perusahaan, seperti Entrust Technologies dan RSA Security menawarkan fungsi SSO yang berbasis kriptografi kunci publik.

2.4

World Wide Web (WWW) Menurut Engst et al (1995), mengatakan bahwa WWW atau lebih dikenal

dengan Web memberikan keistimewaan yang sangat penting untuk internet. Web menyediakan akses untuk huruf, ukuran, dan tipe dari teks, dan juga dapat dimasukkan gambar pada tampilan dengan perlakuan yang biasa. Suara dan film juga mungkin dimasukkan. Web juga menyediakan hypertext, yang

menghubungkan dokumen manapun di dalam Web, tidak hanya pada satu mesin.

27

Hypertext merupakan sebuah konsep yang kuat yang mengijinkan pembaca untuk mengendalikan fleksibilitas lewat sebagaian link dari informasi. Menurut Turban et al (2005, pp482), menjelaskan bahwa WWW tidak serupa dengan Internet. Fungsi Internet adalah sebagai mekanisme transport. Sedangkan WWW adalah sebuah aplikasi yang menggunakan fungsi transport itu. Aplikasi lain juga dapat berjalan dalam Internet. Web merupakan sebuah sistem dengan standar universal yang dapat diterima untuk penyimpanan, pengambilan, pembuatan/pembentukan, dan menampilkan informasi lewat arsitektur

client/server. Web menangani semua tipe informasi digital, termasuk teks, hypermedia, grafik, dan suara. Web menggunakan user interface berupa grafik. Web yang berdasarkan standar bahasa hypertext dinamakan Hypertext Markup Language (HTML), dimana format dokumen dan penggabungan link hypertext yang dinamik untuk dokumen lain disimpan pada komputer yang sama atau berbeda.

2.5

Web Portal Web portal merupakan sebuah teknologi yang akan berkembang pada

teknologi web di masa depan. Satu halaman portal terdiri dari berbagai macam portlets yang dapat mengirimkan informasi dari banyak sumber (Braun et al, 2004). Selain informasi web portal juga dapat menggabungkan berbagai aplikasi web menjadi satu kesatuan, sebagai contoh adalah sharing content, digital cinema, e-learning, dll (Mannaert et al, 2003).

28

2.6

WordPress WordPress adalah aplikasi blog dan content management system yang

ditulis menggunakan bahasa php. WordPress adalah pengembangan dari b2/cafelog yang dikembangkan oleh Michel Vardighi. Pada bulan Mei 2003 wordpress rilis pertama diluncurkan. WordPress juga mendukung penggunaan blog multi user dengan mengaktifkan plugin multi user.

2.7 Zimbra Collaboration Suites (ZCS)

Menurut Tuxkeren (2012:3) Zimbra Collaboration Suites (ZCS) atau yang lebih dikenal dengan Zimbra adalah sebuah produk Groupware yang dibuat oleh Zimbra, Inc yang berlokasi di Palo Alto, California, Amerika Serikat. Pada masa awal-awalnya perusahaan ini dibeli oleh Yahoo! Tepatnya pada bulan September 2007. Pada awal tahun 2010, Zimbra dibeli oleh VMWare. Aplikasi Zimbra sendiri dibuat menjadi dua bagian komponenn yang bersifat Client dan Server. Zimbra juga memiliki dua model lisensi, yaitu komersial dengan nama produk Zimbra Network Edition, dan Zimbra Appliance yang bersifat virtualisasi serta sebuah lisensi lagi yang bersifat open sources. Zimbra web client ada sebuah perangkat kolaborasi yang penuh dengan menggunakan teknologi AJAX, sehingga fitur-fitur seperti tool tips, drag and drop item, dan klik kanan dapat dilakukan di internet browser, juga ditambah lagi

29

dengan addons yang dinamakan Zimlet sehingga membuat Zimbra menjadi kaya fitur. Sementara untuk Zimbra server, menggunakan teknologi dari beberapa aplikasi open sources yang sudah matang dan stabil, yang meliputi aplikasi MTA, POP3, LDAP, MySQL dan lain-lain. Zimbra server sendiri dapat di install di beberapa distro linux yang terkenal. Pembuat Zimbra pertama kalinya adalah Mr. Scott Dietzen, nama Zimbra sendiri terinspirasi dari lagu pop tahun 70an yang berjudul I Zimbra yang dibawakan group band Talking Heads.

2.8 System Flowcart 2.8.1 Flowchart Adalah penyajian yang sistematis tentang proses dan logika dari kegiatan penanganan informasi atau penggambaran secara grafik dari langkah-langkah dan urut-urutan prosedur dari suatu program. Flowchart menolong analis dan programmer untuk memecahkan masalah kedalam segmen-segmen yang lebih kecil dan menolong dalam menganalisis alternatif-alternatif lain dalam pengoperasian. (Anharku, 2009:1)

2.8.2 System flowchart Adalah urutan proses dalam system dengan menunjukkan alat media input, output serta jenis media penyimpanan dalam proses pengolahan data. (Aharku, 2009:1)

30

Pedoman-Pedoman Dalam Membuat Flowchart Jika seorang analis dan programmer akan membuat flowchart, ada beberapa petunjuk yang harus diperhatikan, seperti : 1. 2. Flowchart digambarkan dari halaman atas ke bawah dan dari kiri ke kanan. Aktivitas yang digambarkan harus didefinisikan secara hati-hati dan definisi ini harus dapat dimengerti oleh pembacanya. 3. 4. Kapan aktivitas dimulai dan berakhir harus ditentukan secara jelas. Setiap langkah dari aktivitas harus diuraikan dengan menggunakan deskripsi kata kerja, misalkan Melakukan penggandaan diri. 5. 6. Setiap langkah dari aktivitas harus berada pada urutan yang benar. Lingkup dan range dari aktifitas yang sedang digambarkan harus ditelusuri dengan hati-hati. Percabangan-percabangan yang memotong aktivitas yang sedang digambarkan tidak perlu digambarkan pada flowchart yang sama. Simbol konektor harus digunakan dan percabangannya diletakan pada halaman yang terpisah atau hilangkan seluruhnya bila percabangannya tidak berkaitan dengan sistem. 7. Menggunakan simbol-simbol flowchart yang standar.

(Anharku, 2009:1)

Simbol simbol Flowchart Dalam membuat system flowchart terdiri dari beberapa simbol-simbol yang mana simbol-simbol ini saling berhubungan satu sama lainnya. Adapun

31

simbol-simbol tersebut diantara lain seperti yang terdapat pada tabel 2.1 dibawah ini. Table 2.1. Simbol-simbol Flowchart Sistem No 1 Simbol Terminator Keterangan Fungsi Pemulaan atau akhir dari program.

Garis Alir (Flow Line)

Arah aliran program

Preparation

Proses inisiasi atau pemberian harga awal.

Tabel 2.1 Lanjutan

No 4 Proses

Simbol

Keterangan Fungsi Proses perhitungan atau proses pengolahan data.

32

Input/output data

Proses input atau output data, informasi parameter,

Predefined Process (Sub Program)

Permulaan sub program atau proses menjalankan sub program.

Decision

Perbandingan pernyataan, penyeleksian data yang memberikan untuk selanjutnya. pilihan langkah

On page connector

Penghubung

bagianyang satu

bagian flowchart berada halaman. 9 Off page connector Penghubung pada

bagianyang

bagian flowchart berada pada

halaman

yang berbeda.

33

(sumber: anharku, 2009:2)