Pengantar Unified Modelling Language (UML)

11 08 2009

from : http://harmiprasetyo.wordpress.com/2006/09/26/pengantar-uniifiied-modelliing-language-uml/#comment-2580

Pendahuluan

Saat ini piranti lunak semakin luas dan besar lingkupnya, sehingga tidak bisa lagi dibuat asal-asalan. Piranti lunak saat ini seharusnya dirancang dengan memperhatikan hal-hal seperti scalability , security , dan eksekusi yang robust walaupun dalam kondisi yang sulit. Selain itu arsitekturnya harus didefinisikan dengan jelas, agar bug mudah ditemukan dan diperbaiki, bahkan oleh orang lain selain programmer aslinya. Keuntungan lain dari perencanaan arsitektur yang matang adalah dimungkinkannya penggunaan kembali modul atau komponen untuk aplikasi piranti lunak lain yang membutuhkan fungsionalitas yang sama. Pemodelan ( modeling ) adalah proses merancang piranti lunak sebelum melakukan pengkodean ( coding ). Model piranti lunak dapat dianalogikan seperti pembuatan blueprint pada pembangunan gedung. Membuat model dari sebuah sistem yang kompleks sangatlah penting karena kita tidak dapat memahami sistem semacam itu secara menyeluruh. Semakin komplek sebuah sistem, semakin penting pula penggunaan teknik pemodelan yang baik. Dengan menggunakan model, diharapkan pengembangan piranti lunak dapat memenuhi semua kebutuhan pengguna dengan lengkap dan tepat, termasuk faktor-faktor seperti scalability, robustness, security , dan sebagainya. Kesuksesan suatu pemodelan piranti lunak ditentukan oleh tiga unsur, yang kemudian terkenal dengan sebuan segitiga sukses ( the triangle for success ). Ketiga unsur tersebut adalah metode pemodelan ( notation ), proses ( process ) dan tool yang digunakan.

Memahami notasi pemodelan tanpa mengetahui cara pemakaian yang sebenarnya (proses) akan membuat proyek gagal. Dan pemahaman terhadap metode pemodelan dan proses disempurnakan dengan penggunaan tool yang tepat.

Apa itu UML

Unified Modelling Language (UML) adalah sebuah “bahasa” yg telah menjadi standar dalam industri untuk visualisasi, merancang dan mendokumentasikan sistem piranti lunak. UML menawarkan sebuah standar untuk merancang model sebuah sistem. Dengan menggunakan UML kita dapat membuat model untuk semua jenis aplikasi piranti lunak, dimana aplikasi tersebut dapat berjalan pada piranti keras, sistem operasi dan jaringan apapun, serta ditulis dalam bahasa pemrograman apapun. Tetapi karena UML juga menggunakan class dan operation dalam konsep dasarnya, maka ia lebih cocok untuk penulisan piranti lunak dalam bahasa bahasa berorientasi objek seperti C++, Java, C# atau VB.NET. Walaupun demikian, UML tetap dapat digunakan untuk modeling aplikasi prosedural dalam VB atau C. Seperti bahasa-bahasa lainnya, UML mendefinisikan notasi dan syntax /semantik. Notasi UML merupakan sekumpulan bentuk khusus untuk menggambarkan berbagai diagram piranti lunak. Setiap bentuk memiliki makna tertentu, dan UML syntax mendefinisikan bagaimana bentuk-bentuk tersebut dapat dikombinasikan. Notasi UML terutama diturunkan dari 3 notasi yang telah ada sebelumnya: Grady Booch OOD (Object-Oriented Design), Jim Rumbaugh OMT (Object Modeling Technique), dan Ivar Jacobson OOSE (Object-Oriented Software Engineering). Sejarah UML sendiri cukup panjang. Sampai era tahun 1990 seperti kita ketahui puluhan metodologi pemodelan berorientasi objek telah bermunculan di dunia. Diantaranya adalah: metodologi booch [1], metodologi coad [2], metodologi OOSE [3], metodologi OMT [4], metodologi shlaer-mellor [5], metodologi wirfs-brock [6], dsb. Masa itu terkenal dengan masa perang metodologi ( method war ) dalam pendesainan berorientasi objek. Masing-masing metodologi membawa notasi sendiri-sendiri, yang mengakibatkan timbul masalah baru apabila kita bekerjasama dengan group/perusahaan lain yang menggunakan metodologi yang berlainan.

 

Dimulai pada bulan Oktober 1994 Booch, Rumbaugh dan Jacobson, yang merupakan tiga tokoh yang boleh dikata metodologinya banyak digunakan mempelopori usaha untuk penyatuan metodologi pendesainan berorientasi objek. Pada tahun 1995 direlease draft pertama dari UML (versi 0.8). Sejak tahun 1996 pengembangan tersebut dikoordinasikan oleh Object Management Group (OMG – http://www.omg.org). Tahun 1997 UML versi 1.1 muncul, dan saat ini versi terbaru adalah versi 1.5 yang dirilis bulan Maret 2003. Booch, Rumbaugh dan Jacobson menyusun tiga buku serial tentang UML pada tahun 1999 [7] [8] [9]. Sejak saat itulah UML telah menjelma menjadi standar bahasa pemodelan untuk aplikasi berorientasi objek.

Konsepsi Dasar UML

Dari berbagai penjelasan rumit yang terdapat di dokumen dan buku-buku UML. Sebenarnya konsepsi dasar UML bisa kita rangkumkan dalam gambar dibawah.

Major Area

View

Diagrams

Main Concepts

structural

static view

class diagram

class, association, generalization, dependency, realization, interface

 

use case view

use case diagram

use case, actor, association, extend, include, use case generalization

 

implementation view

component diagram

component, interface, dependency, realization

dynamic

state machine view

statechart diagram

state, event, transition, action

 

actifity view

activity diagram

state, activity, completion transition, fork, join

 

interaction view

sequence diagram

interaction, object, message, activation

 

colaborating diagram

collaborating, interaction, collaboration rule, message

model management

model management view

class diagram

package, subsystem, model

extensibility

all

all

constraint, stereotype, tagged values

Abstraksi konsep dasar UML yang terdiri dari structural classification , dynamic behavior , dan model management , bisa kita pahami dengan mudah apabila kita melihat gambar diatas dari Diagrams . Main concepts bisa kita pandang sebagai term yang akan muncul pada saat kita membuat diagram. Dan view adalah kategori dari diagaram tersebut. Lalu darimana kita mulai ? Untuk menguasai UML, sebenarnya cukup dua hal yang harus kita perhatikan:

1. Menguasai pembuatan diagram UML

2. Menguasai langkah-langkah dalam analisa dan pengembangan dengan UML

Tulisan ini pada intinya akan mengupas kedua hal tersebut.

Seperti juga tercantum pada gambar diatas UML mendefinisikan diagram-diagram sebagai berikut:

use case diagram

class diagram

statechart diagram

activity diagram

sequence diagram

collaboration diagram

component diagram

deployment diagram

 

Use Case Diagram

Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Sebuah use case merepresentasikan sebuah interaksi antara aktor dengan sistem. Use case merupakan sebuah pekerjaan tertentu, misalnya login ke sistem, meng- create sebuah daftar belanja, dan sebagainya. Seorang/sebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan sistem untuk melakukan pekerjaan-pekerjaan tertentu. Use case diagram dapat sangat membantu bila kita sedang menyusun requirement sebuah sistem, mengkomunikasikan rancangan dengan klien, dan merancang test case untuk semua feature yang ada pada sistem. Sebuah use case dapat meng- include fungsionalitas use case lain sebagai bagian dari proses dalam dirinya. Secara umum diasumsikan bahwa use case yang di- include akan dipanggil setiap kali use case yang meng- include dieksekusi secara normal. Sebuah use case dapat di- include oleh lebih dari satu use case lain, sehingga duplikasi fungsionalitas dapat dihindari dengan cara menarik keluar fungsionalitas yang common . Sebuah use case juga dapat meng- extend use case lain dengan behaviour -nya sendiri. Sementara hubungan generalisasi antar use case menunjukkan bahwa use case yang satu merupakan spesialisasi dari yang lain.

Class Diagram

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.

Class memiliki tiga area pokok :

1. Nama (dan stereotype)

2. Atribut

3. Metoda

Atribut dan metoda dapat memiliki salah satu sifat berikut :

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

 

Class dapat merupakan implementasi dari sebuah interface , yaitu class abstrak yang hanya memiliki metoda. Interface tidak dapat langsung diinstansiasikan, tetapi harus diimplementasikan dahulu menjadi sebuah class. Dengan demikian interface mendukung resolusi metoda pada saat run-time .

 

Sesuai dengan perkembangan class model, class dapat dikelompokkan menjadi package . Kita juga dapat membuat diagram yang terdiri atas package .

 

Hubungan Antar Class

  1. Asosiasi, yaitu hubungan statis antar class . Umumnya menggambarkan class yang memiliki atribut berupa class lain, atau class yang harus mengetahui eksistensi class lain. Panah navigability m enunjukkan arah query antar class .
  2. Agregasi, yaitu hubungan yang menyatakan bagian (“terdiri atas..”).
  3. Pewarisan, yaitu hubungan hirarkis antar class . Class dapat diturunkan dari class lain dan mewarisi semua atribut dan metoda class asalnya dan menambahkan fungsionalitas baru, sehingga ia disebut anak dari class yang diwarisinya. Kebalikan dari pewarisan adalah generalisasi.
  4. Hubungan dinamis, yaitu rangkaian pesan ( message ) yang di- passing dari satu class kepada class lain. Hubungan dinamis dapat digambarkan dengan menggunakan sequence diagram yang akan dijelaskan kemudian.

 

Statechart Diagram

Statechart diagram menggambarkan transisi dan perubahan keadaan (dari satu state ke state lainnya) suatu objek pada sistem sebagai akibat dari stimuli yang diterima. Pada umumnya statechart diagram menggambarkan class tertentu (satu class dapat memiliki lebih dari satu statechart diagram ). Dalam UML, state digambarkan berbentuk segiempat dengan sudut membulat dan memiliki nama sesuai kondisinya saat itu. Transisi antar state umumnya memiliki kondisi guard yang merupakan syarat terjadinya transisi yang bersangkutan, dituliskan dalam kurung siku. Action yang dilakukan sebagai akibat dari event tertentu dituliskan dengan diawali garis miring. Titik awal dan akhir digambarkan berbentuk lingkaran berwarna penuh dan berwarna setengah.

 

Activity Diagram

Activity diagrams menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang, bagaimana masing-masing alir berawal, decision yang mungkin terjadi, dan bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi. Activity diagram merupakan state diagram khusus, di mana sebagian besar state adalah action dan sebagian besar transisi di- trigger oleh selesainya state sebelumnya ( internal processing ). Oleh karena itu activity diagram tidak menggambarkan behaviour internal sebuah sistem (dan interaksi antar subsistem) secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas dari level atas secara umum. Sebuah aktivitas dapat direalisasikan oleh satu use case atau lebih. Aktivitas menggambarkan proses yang berjalan, sementara use case menggambarkan bagaimana aktor menggunakan sistem untuk melakukan aktivitas. Sama seperti state , standar UML menggunakan segiempat dengan sudut membulat untuk menggambarkan aktivitas. Decision digunakan untuk menggambarkan behaviour pada kondisi tertentu. Untuk mengilustrasikan proses-proses paralel ( fork dan join ) digunakan titik sinkronisasi yang dapat berupa titik, garis horizontal atau vertikal. Activity diagram dapat dibagi menjadi beberapa object swimlane untuk menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu.

 

Sequence Diagram

Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem (termasuk pengguna, display , dan sebagainya) berupa message yang digambarkan terhadap waktu. Sequence diagram terdiri atar dimensi vertikal (waktu) dan dimensi horizontal (objek-objek yang terkait). Sequence diagram biasa digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah yang dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu. Diawali dari apa yang men- trigger aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara internal dan output apa yang dihasilkan. Masing-masing objek, termasuk aktor, memiliki lifeline vertikal. Message digambarkan sebagai garis berpanah dari satu objek ke objek lainnya. Pada fase desain berikutnya, message akan dipetakan menjadi operasi/metoda dari class . Activation bar menunjukkan lamanya eksekusi sebuah proses, biasanya diawali dengan diterimanya sebuah message.

Untuk objek-objek yang memiliki sifat khusus, standar UML mendefinisikan icon khusus untuk objek boundary, controller dan persistent entity .

Collaboration Diagram

Collaboration diagram juga menggambarkan interaksi antar objek seperti sequence diagram , tetapi lebih menekankan pada peran masing-masing objek dan bukan pada waktu penyampaian message . Setiap message memiliki sequence number , di mana message dari level tertinggi memiliki nomor 1. Messages dari level yang sama memiliki prefiks yang sama.

Component Diagram

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

Deployment Diagram

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

Langkah-Langkah Penggunaan UML

Berikut ini adalah tips pengembangan piranti lunak dengan menggunakan UML:

  1. Buatlah daftar business process dari level tertinggi untuk mendefinisikan aktivitas dan proses yang mungkin muncul.
  2. Petakan use case untuk tiap business process untuk mendefinisikan dengan tepat fungsionalitas yang harus disediakan oleh sistem. Kemudian perhalus use case diagram dan lengkapi dengan requirement, constraints dan catatan-catatan lain.
  3. Buatlah deployment diagram secara kasar untuk mendefinisikan arsitektur fisik sistem.
  4. Definisikan requirement lain (non-fungsional, security dan sebagainya) yang juga harus disediakan oleh sistem.
  5. Berdasarkan use case diagram , mulailah membuat activity diagram .
  6. Definisikan objek-objek level atas ( package atau domain ) dan buatlah sequence dan/atau collaboration diagram untuk tiap alir pekerjaan. Jika sebuah use case memiliki kemungkinan alir normal dan error, buatlah satu diagram untuk masing-masing alir.
  7. Buarlah rancangan user interface model yang menyediakan antarmuka bagi pengguna untuk menjalankan skenario use case .
  8. Berdasarkan model-model yang sudah ada, buatlah class diagram . Setiap package atau domain d ipecah menjadi hirarki class lengkap dengan atribut dan metodanya. Akan lebih baik jika untuk setiap class dibuat unit test untuk menguji fungsionalitas class dan interaksi dengan class lain.
  9. Setelah class diagram dibuat, kita dapat melihat kemungkinan pengelompokan class menjadi komponen-komponen. Karena itu buatlah component diagram pada tahap ini. Juga, definisikan tes integrasi untuk setiap komponen meyakinkan ia berinteraksi dengan baik.
  10. Perhalus deployment diagram yang sudah dibuat. Detilkan kemampuan dan requirement piranti lunak, sistem operasi, jaringan, dan sebagainya. Petakan komponen ke dalam node.
  11. Mulailah membangun sistem. Ada dua pendekatan yang dapat digunakan :
    • Pendekatan use case , dengan meng- assign setiap use case kepada tim pengembang tertentu untuk mengembangkan unit code yang lengkap dengan tes.
    • Pendekatan komponen, yaitu meng- assign setiap komponen kepada tim pengembang tertentu.

• Lakukan uji modul dan uji integrasi serta perbaiki model berserta code nya. Model harus selalu sesuai dengan code yang aktual.

• Piranti lunak siap dirilis.

Tool Yang Mendukung UML

Saat ini banyak sekali tool pendesainan yang mendukung UML, baik itu tool komersial maupun opensource. Beberapa diantaranya adalah:

  • Rational Rose (www.rational.com)
  • Together (www.togethersoft.com)
  • Object Domain (www.objectdomain.com)
  • Jvision (www.object-insight.com)
  • Objecteering (www.objecteering.com)
  • MagicDraw (www.nomagic.com/magicdrawuml)
  • Visual Object Modeller (www.visualobject.com)

Data seluruh tool yang mendukung UML, lengkap beserta harganya (dalam US dolar) bisa dipelajari di situs http://www.objectsbydesign.com/tools/umltools_byCompany.html . Disamping itu, daftar tool UML berikut fungsi dan perbangingan kemampuannya juga dapat dilihat di http://www.jeckle.de/umltools.htm .

 

Pointer Penting UML

Sebagai referensi dalam mempelajari dan menggunakan UML, situs-situs yang merupakan pointer penting adalah:

Dan juga buku-buku yang terdapat di daftar pustaka.

Daftar Pustaka

  1. Grady Booch, Object-Oriented Analysis and Design with Application, Benjamin/Cummings, 1991.
  2. Peter Coad and Edward Yourdon, Object-Oriented Analysis, Yourdon Press, 1991.
  3. Ivar Jacobson, Magnus Christerson, Patrik Jonson, and Gunnar Overgaard, Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, 1992.
  4. James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William Lorenson, Object-Oriented Modeling and Design, Prentice Hall, 1991.
  5. Sally Shlaer and Stephen J. Mellor, Object-Oriented System Analysis: Modeling the World in Data, Yourdon Press, 1988.
  6. Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener, Designing Object-Oriented Software, Prentice Hall, 1990.
  7. Grady Booch, James Rumbaugh, and Ivar Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, 1999.
  8. Ivar Jacobson, Grady Booch, and James Rumbaugh, The Unified Software Development Process, Addison-Wesley, 1999.
  9. James Rumbaugh, Ivar Jacobson, and Grady Booch, The Unified Modeling Language Reference Manual, Addison-Wesley, 1999.
  10. Unified Modeling Language Specification, Object Management Group, http://www.omg.org, 1999.
  11. Introduction to OMG UML [http://www.omg.org/gettingstarted/what_is_uml.htm]
  12. UML Tutorial [http://www.sparxsystems.com.au/UML_Tutorial.htm]
  13. Embarcadero Tech Support [http://www.embarcadero.com/support/uml_central.asp]
  14. Practical UML A Hands-On Introduction for Developers, http://www.togethersoft.com/services/practical_guides/umlonlinecourse/index.html%5D
  15. Architecture and Design: Unified Modeling Language (UML), [http://www.cetuslinks. org/oo_uml.html]




REQUIREMENT ENGINEERING

10 08 2009

Oleh : Teguh Sutopo

1. Definisi dan Pentingnya Rekayasa Kebutuhan.

Rekayasa Kebutuhan (Requirement Engineering) adalah bagian yang tak terpisahkan dari kegiatan rekayasa perangkat lunak. Rekayasa Kebutuhan mempunyai peran yang cukup penting, bahkan akan menentukan keberhasilan dari suatu proyek rekayasa perangkat lunak. Mengenai peran penting rekayasa kebutuhan tersebut telah banyak dikemukakan oleh para pakar.

Requirements engineering merupakan fase terdepan dari proses rekayasa perangkat lunak (software engineering), dimana software requirements (kebutuhan) dari user (pengguna) dan customer (pelanggan) dikumpulkan, dipahami dan ditetapkan. Para pakar software engineering sepakat bahwa requirements engineering adalah suatu pekerjaan yang sangat penting. Fakta membuktikan bahwa kebanyakan kegagalan pengembangan software disebabkan karena adaya ketidakkonsistenan (inconsistent), ketidaklengkapan (incomplete), maupun ketidakbenaran (incorrect) dari requirements specification (spesifikasi kebutuhan) [Rom-01].

Juga beberapa definisi dan hukum yang dikemukakan pakar mengenai requirement engineering sebagai berikut :

1. Requirement Engineering adalah proses menentukan properti tertentu dari sistem yang harus ada, dengan kata lain, menentukan komponen-komponen sistem. Kebutuhan proses menghasilkan informasi tentang desain yang akan menjadi dasar. Untuk ini, harus mengetahui dimana sebuah sistem akan digunakan, oleh siapa, dan layanan apa yang harus disediakan. Juga penting untuk menentukan kompromi apa yang dapat dilakukan jika terjadi konflik kebutuhan. Kita berasumsi bahwa setiap sistem memiliki kumpulan fungsi yang berguna, yang penting untuk keberhasilan [Alb-2003].

2. Software requirements berisikan kebutuhan dan kendala yang ditempatkan pada produk perangkat lunak yang memberikan kontribusi pada solusi dari beberapa masalah dunia nyata [Kot-2000].

3. Rekayasa Kebutuhan membantu para ahli perangkat lunak untuk lebih memahami masalah dan menyelesaikannya. Ini meliputi kumpulan dari tugas-tugas yang mengarah ke pemahaman tentang apa yang akan menjadi dampak dari bisnis perangkat lunak, apa yang diinginkan oleh pelanggan, dan bagaimana pemakai akan berinteraksi dengan perangkat lunak [Pre-2005].

4. Beberapa hukum dalam requirement engineering yang tercantum dalam SWEBOK edisi 2004 adalah sebagai berikut:

a. Hukum Glass (Robert Glass)

Kekurangan kebutuhan (requirement deficiences) adalah sumber utama dari kegagalan proyek. Kekurangan kebutuhan menimbulkan masalah di banyak proyek.

Kebutuhan yang ditentukan mungkin salah, atau tidak cukup perhatian yang diberikan pada definisi kebutuhan. Menetapkan tujuan dengan benar untuk setiap proyek adalah persyaratan tugas. Meskipun ada proyek dipahami dengan baik, ditentukan, dan kebutuhan stabil, lebih sering bukan ini masalahnya. Lebih khusus tidak lengkap atau kesalahan definisi kebutuhan, definisi terutama jika dilakukan oleh pihak ketiga untuk pelanggan dan pengembang.

Teori: Menentukan kebutuhan yang tepat merupakan masalah berat. Alasan utama untuk ini adalah kebutuhan yang berbeda dari berbagai kelompok pengguna, konflik kepentingan antara orang atau kelompok yang terlibat, dan kesulitan dari konflik antara prioritas kebutuhan. Definisi kebutuhan adalah proses belajar dan negosiasi. Kedua para pengembang dan pengguna belajar sambil menerapkan atau menggunakan sistem. Pengetahuan dari setiap orang yang terlibat sangat terbatas. Orang tidak tahu semuanya dan banyak lupa. Berbagi pengetahuan tidak terjadi dengan sendirinya. Masalah-masalah yang melekat dan tidak akan hilang sebagai kelangsungan teknologi.

b. Hukum Boehm pertama

Kesalahan yang paling sering selama menentukan kebutuhan (requirements) adalah kegiatan desain yang lebih mahal.

Studi ini berkaitan dengan analisis kesalahan yang dibuat oleh pengembang. Ketika menganalisis kesalahan, pertanyaan pertama adalah: “Di mana dalam proses pembangunan kesalahan ini telah dibuat?” Ini mengarah ke salah satu pekerjaan dari kesalahan ke setiap tahapan atau kegiatan di Lifecycle. Hukum ini menggabungkan dua observasi yang erat kaitannya.

gmb1_re

Gambar 1. Cost of problems per phase

Teori: Manusia biasanya mempunyai masalah jika banyak situasi perlu pemikiran pada saat yang bersamaan. Kita cenderung untuk berpikir baris utamanya saja, dan melupakan kasus khusus. Bahkan jika pikiran manusia mendukung pemrosesan paralel, ini tidak berarti bahwa perbedaan berbagai unit investigasi di berbagai penjuru. Kami memiliki arti yang tidak melekat atau mekanisme untuk mencari domain secara mendalam (kecuali dapat diwakili secara visual). Kesalahan dari kelalaian lebih sering daripada kesalah-pahaman.

c. Hukum Boehm kedua

Prototyping (secara signifikan) mengurangi kebutuhan dan kesalahan desain, terutama untuk user interface.

Hukum ini menempatkan penekanan pada pengurangan kesalahan. Pengurangan kesalahan membawa penurunan biaya juga. Jumlah pengurangan tidak terukur, namun, menjadi signifikan, setidaknya 20-30 persen harus terjadi. Hal ini berlaku untuk semua hukum, meskipun kata ‘signifikan’ akan diabaikan. Perubahan dalam kisaran 5-20 persen karena perbedaan pengukuran atau setup, atau dapat disebabkan oleh gangguan tak terkendalikan.

gmb2_re

Gambar 2. Prototypes in the system lifecycle

Teori: Prototip memberikan pandangan dari sistem yang tampak nyata bagi pengguna. Berbeda dengan representasi desain lainnya, prototip tidak bergantung pada kekuatan imajinasi orang untuk memvisualisasikannya. Ini adalah perwujudan sebagian sistem yang sesungguhnya, bukan yang abstrak. Mungkin lebih menekankan detil dan dengan demikian tidak menyembunyikan atau merusak penampakan total dari sistem. Prototip perlu dibuat untuk sistem di bawah pengembangan saja, bukan untuk sistem yang ada.

d. Hukum Davis

Nilai dari sebuah model tergantung pada pandangan diambil, tetapi tidak ada yang terbaik untuk semua tujuan.

Model adalah bentuk yang sangat berguna untuk menjelaskan sistem. Hal ini berlaku sebelum, selama, dan sesudah pengembangan sistem. Contoh model yang digunakan dalam ilmu alam adalah model yang menggambarkan evolusi bintang, model atom atau pengoperasian sel. Model tersebut konsep intelektual yang pertama, namun dapat diwujudkan atau dinyatakan dalam sebuah representasi yang terlihat. Dalam ilmu komputer, kita dapat menggunakan model untuk mempelajari struktur statis objek sistem atau komponen, struktur logika data yang digunakan, atau struktur dinamis interaksi tugas dan proses.

 tbl1_re

Tabel 1. Modeling views and notations

Teori: Sebuah model dari realitas membantu untuk menjelaskan pemahaman. Model merupakan penjelasan dari sistem. Model taklangsung terlihat atau abstrak, berangkat dari hal-hal yang tidak dianggap penting untuk sementara waktu. Abstraksi berguna untuk beberapa jenis pemahaman manusia saja. Abstraksi merupakan pengetahuan konseptual yang ditingkatkan. Tidak semua pengguna perlu, ingin atau bahkan akan mentolerir abstraksi ini. Dari sudut pandang sistem yang akan dibangun, abstraksi berangkat dari kenyataan yang tergantung pada notasi yang digunakan, yang sering menipu pengamat. Gerakan bintang dalam gugus bintang, atau orbit elektron dalam model atom, hanya ada satu persamaan kusam pada kenyataan. Namun demikian, model-model seperti itu sering digunakan untuk tujuan yang bermanfaat.

 

Dalam mendefiniskan kebutuhan, tentu melibatkan beberapa pihak. Pihak-pihak yang berpartisipasi dalam proses definisi kebutuhan secara kolektif disebut sebagai pihak yang berkepentingan (stakeholders). Jika sistem yang dibangun untuk diketahui pelanggan, kebutuhan mungkin merupakan dasar untuk pembuatan kontrak. Jika pelanggan tidak mengetahui awalnya, organisasi pemasaran dapat mengasumsikan fungsi ini. Pada awalnya, kebutuhan dibahas di tingkat aplikasi. Hal ini tidak selalu nampak jelas apakah kebutuhan tersebut akan diimplementasikan dalam perangkat keras atau perangkat lunak, atau dilakukan oleh manusia. Kebutuhan itu harus selalu dianggap sebagai kebutuhan sistem. Kebutuhan perangkat lunak hanya merupakan bagian dari keseluruhan. Kebutuhan perangkat lunak akan ditentukan setelah kebutuhan sistem, atau berasal dari keseluruhan.

Hasil dari fase requirements engineering terdokumentasi dalam requirements specification. Requirements specification berisi kesepakatan bersama tentang permasalahan yang ingin dipecahkan antara pengembang dan pelanggan, dan merupakan titik start menuju proses berikutnya yaitu software design. Sistemisasi proses negosiasi pengembang dan pelanggan dalam requirements engineering dibagi dalam 3 proses besar yaitu: elicitation, specification, validation and verification. Formula ini kemudian juga dikenal dengan nama The Three Dimensions of Requirements Engineering. Proses requirements engineering ini dilakukan secara iterasi dengan mengakomodasi adanya feedback dari customer (user). [Rom-01].

gmb3_re

Gambar 3, The three dimensions of requirement engineering

Kualitas produk biasanya ditetapkan sebagai derajat untuk memenuhi kebutuhan pelanggan. Pandangan ini menekankan satu sisi kualitas: perspektif pengguna. Yang lebih komprehensif dilihat juga termasuk sisi pengembang atau produsen. 

tbl2_re Tabel 2, Kriteria penting kualitas perangkat lunak [SWE-2004]

Kualitas produk perangkat lunak dari sudut pandang pengguna dapat dinyatakan sebagai pemenuhan dari beberapa properti: ketersediaan, keandalan, efisiensi, installability, kegunaan, ketahanan, dan keselamatan/keamanan. Selain itu, beberapa kriteria dapat ditambahkan jika pengembang berkeinginan. Kriteria ini adalah testability, maintainability, localizability, portability, dan reusability. Sebuah definisi singkat dari masing-masing kriteria diberikan dalam tabel 1. Properti ini, kehandalan (reliability) biasanya yang paling penting dan sering digunakan sebagai sinonim untuk kualitas. Dalam hal produk perangkat lunak, kehandalan (dan karena kehandalan jadi berkualitas) yang sering dinyatakan sebagai jumlah kesalahan atau cacat per seribu baris kode (cacat/KLOC). Masalahnya adalah bahwa ini adalah pengukuran berorientasi pengembang (developer-oriented). Pengukuran berorientasi pengguna untuk keandalan adalah jumlah masalah pengguna per bulan. Hubungan antara kedua pengukuran adalah rumit dan tergantung pada penggunaan sistem yang sebenarnya. Sistem ketersediaan adalah fungsi dari jumlah dan lama interupsi. Salah satu definisi yang populer adalah:

Availability = MTTF/(MTTF + MTTR)

dimana MTTF = waktu (lamanya) kegagalan dan MTTR = waktu untuk perbaikan. Satuan yang digunakan dalam persen (mis. 99,9%).

Software Requirement (Requirement Engineering) memiliki cakupan dan pendekatan pengetahuan yang cukup luas sehingga perlu dibagi-bagi dalam beberapa sub bidang. Pembagian KA yang kompatibel dengan bagian dari IEEE 12207 yang merujuk ke kebutuhan kegiatan. Risiko yang melekat dalam usulan pembagian adalah seperti sebuah proses air terjun (a waterfall-like process) yang dapat diduga/disimpulkan. Untuk menjaga hal ini, subarea 2 proses kebutuhan, dirancang untuk menyediakan gambaran tingkat tinggi proses kebutuhan dengan pengaturan sumber daya dan batasan dalam proses operasi dan yang bertindak untuk mengkonfigurasinya.

Kebutuhan Software KA terkait erat dengan Desain, Testing, Pemeliharaan, Manajemen Konfigurasi, Manajemen Rekayasa Perangkat Lunak, Proses Rekayasa Perangkat Lunak, dan Ranah Kualitas Perangkat Lunak.

Dalam SWEBOK edisi 2004, Ranah Pengetahuan Kebutuhan Perangkat Lunak (The Software Requirements Knowledge Area / KA) meliputi pengungkapan, analisis, spesifikasi, dan validasi kebutuhan perangkat lunak. Berikut adalah diagram pembagian software requirement [SWE-2004]:

gmb4_re

Gambar 4. Breakdown of topics for the Software Requirements KA

2. Kegiatan Rekayasa Kebutuhan (Requirement Engineering Tasks)

Kegiatan dalam rekayasa kebutuhan memiliki aspek penting dalam menunjang kesuksesan proyek rekayasa perangkat lunak. Adapun kegiatan-kegiatan tersebut adalah sebagai berikut:

1) Pernyataan Visi (Vision statement)

Pernyataan visi dari sistem yang akan dibangun merupakan hal baik untuk memulai proses kebutuhan. Visi dituangkan dalam bentuk dokumen yang menguraikan keseluruhan tujuan yang harus dicapai dan disetujui oleh stakeholders, terutama di tingkat manajemen. Jika dalam proses ternyata visi tidak dapat dicapai, pernyataan visi harus direvisi dan dibahas kembali.

2) Pengungkapan Kebutuhan dan Prioritas (Requirements elicitation and prioritization)

Kebutuhan harus dikumpulkan dari sumber yang dapat berkontribusi. Kontribusi terutama dari calon pelanggan dan pengguna. Jika dana tidak datang langsung dari pelanggan, mungkin ada kelompok lain yang memiliki minat dan pengaruh. Selain itu, pihak ketiga ahli hukum yang berwenang, dan badan standar mungkin memiliki masukan. Namun, Kebutuhan yang diharapkan pengguna harus mendapatkan prioritas utama. Oleh karena itu, harus dipahami siapa pengguna, dan apa keterampilan mereka, motivasi dan lingkungan kerja [Alb-2003]. Proses ini tidak mudah karena: batasan sistem sering tidak jelas, klien tidak cukup paham apa yang dibutuhkan dan kebutuhan sering berubah [Pre-2005].

3) Pengetahuan akuisisi dan pengelolaan

Dalam banyak kasus, kebutuhan proses tergantung pada pendapat, klarifikasi, dan kumpulan masalah berorientasi pengetahuan. Hal ini terkait dengan aplikasi domain tertentu. Tanpa pengetahuan ini, kita tidak dapat menentukan fungsi apa yang harus ada pada sistem yang direncanakan. Jika ada pengetahuan, orang harus didorong untuk bersedia membuatnya [Alb-2003].

Kadang masalah yang muncul berakar dari perbedaan disiplin ilmu yang dimiliki. Customer adalah expert pada domain yang softwarenya ingin dikembangkan (domain specialist), dilain pihak sang pengembang (requirements analyst) adakalanya sama sekali buta terhadap knowledge domain tersebut, meskipun tentu memahami dengan benar bagaimana sebuah software harus dikembangkan. Gap knowledge domain tersebut yang diharapkan bisa diatasi dengan adanya interaksi terus menerus dan berulang (iterasi) antara pengembang dan customer. Proses interaksi tersebut kemudian dimodelkan menjadi beberapa teknik dan metodologi diantaranya adalah interviewing, brainstorming, prototyping, use case, dsb. [Rom-01].

4) Studi Kelayakan atau analisis risiko

Untuk sistem yang lebih besar, studi kelayakan perlu dilakukan sebelum kebutuhan secara resmi diterima. Dalam proses ini, untuk mendapatkan jawaban atas pertanyaan berikut pada setiap item pada daftar kebutuhan harus diperoleh: “Apakah kebutuhan ini akan dipenuhi dengan pengetahuan dan teknologi yang tersedia saat ini?” Ini dapat diperluas melengkapi analisis risiko. Dalam hal ini, pembongkaran non-teknis akan diberikan juga. Ini dapat berhubungan dengan pertanyaan seperti: “Bisakah ini dikembangkan atau dibangun dalam waktu yang telah dialokasikan?” “Apakah anggaran memadai?” dan “Apakah ada pembongkaran yang kompetitif?” Untuk menjawab pertanyaan-pertanyaan ini, satu bentuk sebagian desain harus dilakukan.

5) Kebutuhan fungsional dan non-fungsional

a. Kebutuhan fungsional , adalah suatu kebutuhan yang menyatakan prilaku yang harus ada pada sistem. Contoh jika seorang pengusaha membeli mobil untuk membawa barang dari gudang ke toko, maka kebutuhan fungsional dari mobil tersebut adalah mobil harus dapat membawa barang dari gudang ke toko.

b. Kebutuhan non fungsional sederhananya adalah batasan yang harus ada pada sistem dan bagaimana dalam membentuk sistem tersebut. Batasan dapat dibagi menjadi dua sub katagori yakni:

  • Performance constraint, batasan ini menunjukan spesifikasi bagaimana sistem bekerja ketika kebutuhan funsional telah bekerja. Contoh pada mobil yang mengangkut barang diatas adalah batasan bahwa minimal daya angkut pada mobil harus lebih dari satu ton.
  • Development constraint, batasan ini menunjukan sebagai pelengkap dari performance constraint. Batasan ini lebih cenderung pada batasan pada level manajemen proyek . Contoh rincian dari waktu , resource, quality , dll.

6) Keselamatan dan Kebutuhan keamanan

Kekhususan bentuk kebutuhan non-fungsional menyangkut keselamatan dan keamanan sistem. Resiko keselamatan dapat menimbulkan bahaya untuk pengguna individu, kelompok, atau masyarakat luas. Keselamatan adalah penting, terutama jika komputer mengendalikan peralatan fisik atau pabrik, seperti rem mobil, pesawat, atau stasiun tenaga nuklir. Keamanan menjadi isu penting jika data yang disimpan, data harus dilindungi terhadap penyalahgunaan, serta terhadap serangan berbahaya oleh pesaing.

7) Dokumentasi Kebutuhan (Documentation of Requirements)

Kebutuhan setelah terkumpul dan teranalisa selanjutnya didokumentasikan dengan jelas dan baik dan tidak ambigu. Penulisan dokumentasi kebutuhan merupakan aspek yang “critical” sehingga memungkinkan suatu iterasi yang melibatkan seluruh ‘stakesholders’ sangatlah mungkin terjadi. Hal ini dapat disimpulkan dari peranan dokumentasi kebutuhan, yaitu :

a. Peran Dokumen Kebutuhan

  • Digunakan sebagai dasar validasi jika terjadi konflik antar ‘stakesholders’
  • Sebagai kontrak antara customer dan developer
  • Dasar dari desain sistem bagi perancang
  • Ukuran bagi manager proyek dalam pemantauan jalannya proyek
  • Sumberdaya untuk manajemen kebutuhan dan pelacakan kebutuhan
  • Sumber untuk memformulasikan test plan untuk QA dan pengujian tim
  • Dasar untuk pengembangan perputaran proyek

b. Spesifikasi Kebutuhan

Ditinjau dari sisi pemakai dokumentasi requirement dapat dipisahkan menjadi dua bagian

  • User requirement , lebih ke bahasa formal non teknis. Diperuntukkan untuk kepentingan pelanggan dan end-user
  • System requirements, lebih ke bahasa formal teknis. Diperuntukan untuk kepentingan perancang dan perekayasa sistem.

Setiap notasi yang digunakan harus mudah dibaca dan diketahui. Jika pemeriksa dan pembaca dokumen tidak memiliki latar belakang ilmu komputer, teks biasa dan diagram sederhana merupakan media pilihan. Untuk menjelaskan sistem bagi pengembang, biasa disertakan kebutuhan model. Untuk keperluan pemodelan, dengan notasi UML diutamakan daripada notasi grafis lainnya. Notasi ini sebagian besar CASE tools, notasi UML Object Modeling Technique (OMT), Entity Relationship Diagrams (ERDs), State Chart, dan notasi Use Case serta Data Flow Diagrams (DFDs)

8) Penerimaan, Validasi dan Persetujuan Kebutuhan

Keberhasilan setiap proyek pembangunan terutama tergantung pada penerimaan dari produk akhir yang diinginkan oleh pengguna. Cara terbaik untuk mencapai ini adalah melalui partisipasi pengguna. Upaya bersama ini selalu dimulai dengan definisi kebutuhan. User harus menerima kebutuhan, yakni mempertimbangkan kebutuhan sebagai milik mereka. Setelah didapat suatu kebutuhan yang teranalisa maka team rekayasa kebutuhan dan para stakeholdes memvalidasi kembali dan meperbaiki apa yang menjadi kekurangan. Meliputi proses identifikasi, menyakin kan kembali, menanggapi dan memperbaiki masalah dari requirements, dan menyatakan bahwa requirement telah dapat diterima.

9) Pelacakan Kebutuhan dan Perubahan kendali

Untuk sistem yang besar, perlu dipastikan bahwa tidak ada dokumentasi kebutuhan yang terlupakan. Kebutuhan dapat berubah, selama kehidupan sebuah proyek, baik sebelum atau setelah pengiriman. Oleh karena itu, diperlukan untuk membuat perubahan kendali prosedur guna kebutuhan. Prosedur ini harus menjamin bahwa semua pihak yang berkepentingan mengetahui tentang perubahan bila usulan, persetujuan untuk mengadopsi, dan tindak lanjut atas semua kegiatan yang dipicu oleh perubahan ini. Hal ini akan berlaku saat menambahkan atau menghapus kode, melakukan tes regresi, dokumentasi atau membuat perubahan.

 

3. Kesimpulan

Definisi Kebutuhan (Requirement Definitions) adalah pernyataan yang menidentifikasikan kebutuhan yang penting dalam sistem dan di dalamnya mencakup aspek kebenaran, realistis, dibutuhkan, tidak ambigu, dan terukur. Langkah yang paling penting dalam proses requirement adalah komunikasi yang akurat antara user yang memerlukan sistem dengan pengembang (developer).

RE yang baik adalah penting karena dampaknya mampu mengurangi biaya proyek, dan diterimanya sistem oleh stakeholder sehingga bisa mengarah kepada keuntungan yang tinggi. Namun juga harus diakui dibutuhkan tenaga dan waktu yang tidak sedikit untuk berinvestasi dalam pembuatan requirement yang benar-benar baik. Untuk mendapatkan requirement yang baik, ada banyak pekerjaan/tasks harus dilakukan, untuk itu tim Requirements Engineering tidak hanya bekerja pada awal dari proyek namun bekerja melalui tahap pengembangan sampai tahap delivery untuk memastikan requirement benar-benar sesuai.

Karena kompleksitas, ragam pengetahuan dan keahlian khusus serta bidang kerja yang banyak, maka Requirement Engineering telah menjadi cabang ilmu baru pada tahun 1990an.

 

Daftar Pustaka

  • [Rom-01] Romi Satria Wahono, “Menyegarkan Kembali Pemahaman tentang Requirement Engineering”, http://romisatriawahono.net/2006/04/29/menyegarkan-kembali-pemahaman-tentang-requirement-engineering/
  • [Alb-2003] Albert Endres, Dieter Rombach, “A Handbook of Software and Systems Engineering : Empirical Observations, Laws and Theories”, Pearson Education Limited, England, 2003.
  • [SWE-2004] SWEBOK, “Chapter 2 : SOFTWARE REQUIREMENTS”, IEEE, 2004.
  • [Pre-2005] Pressman, Roger S., “Software Engineering: A Practitioner’s Approach”, 6th Edition. McGraw-Hill. 2005.
  • [Kot-2000] G. Kotonya and I. Sommerville, Requirements Engineering: Processes and Techniques, John Wiley & Sons, 2000.




ANEKA PENGOLAHAN PRODUK PERTANIAN

4 08 2009

aneka00

Instalasi Penelitian dan Pengkajian Teknologi Pertanian
DKI Jakarta
1996 / 1997

KATA PENGANTAR

Pasca panen produk pertanian di DKI Jakarta merupakan salah satu cabang usaha pertanian yang mempunyai prospek yang cukup baik untuk dikembangkan dimasa mendatang. Selain dapat meningkatkan pendapatan para petani pengolah pasca panen, juga dapat memperluas kesempatan berusaha bagi warga DKI Jakarta, serta dapat menyerap kelebihan produk pertanian segar untuk dijadikan aneka produk olahan.

Peluang tersebut perlu didukung dengan ketersediaan teknologi yang telah dihasilkan oleh lembaga penelitian dan diterapkan di kelompok-kelompok tani.

Brosur ini merupakan kumpulan beberapa informasi teknologi yang berasal dari Pusat Penelitian dan Pengembangan Hortikultura, Dinas Pertanian DKI Jakarta dan beberapa informasi langsung dari kelompok tani nelayan seperti kelompok Wanita tani Widya Tani dan Kelompok Wanita tani Ayu Lestari di Jakarta Selatan serta Kelompok Wanita tani Ganda Mekar dan Kelompok Mekar Sari Jakarta Timur.

Ucapan terima kasih disampaikan kepada Ibu Nuraesin dari kelompok Mekar Sari, Ibu Sri Yunani Sueb dari kelompok Ganda Mekar, Ibu Yanti dari Kelompok Wanita tani Ayu
Lestari dan Ibu Farida Edi dari Kelompok Wanita tani Widya Tani. atas kerjasamanva dalam pengumpulan bahan-bahan dan informasi hingga ini tersusun.

I. PENDAHULUAN

Sebagian besar produk pertanian, khususnya buah-buahan dan sayuran lebih banyak dikonsumsi dalam bentuk segar dari pada dalam bentuk olahan. Disamping mengandung bahan-bahan seperti protein, karbohidrat dan vitamin masih cukup tinggi,
juga masih mempunyai cita rasa yang segar dan menarik. Namun demikian karma sifat
dari produk pertanian itu sendiri yang mudah busuk dan rusak maka alternatif untuk diolah menjadi produk pasta panen merupakan hal yang bijaksana untuk di lakukan. Tingkat kerusakan produk pertanian khususnya buah dan sayuran diperkirakan sekitar 30 % sampai dengan 40 % , sedangkan 60 % dikonsumsi dalam bentuk segar dan olahan.

DKI Jakarta yang merupakan pusat pemasaran produk pertanian mempunyai peluang yang cukup besar bagi penyediaan produk pertanian seperti buah-buahan dan sayuran sebagai bahan baku olahan produk pertanian. Produk olahan pertanian selain dapat meningkatkan nilai tambah bagi produk pertanian tersebut juga dapat memperluas aneka produk pertanian menjadi beberapa produk olahan serta dapat meningkatkan pendapatan pare pengolahan pasta panen.

Perkembangan teknologi pengolahan buah-buahan yang merupakan hasil penelitian Pusat Penelitian Hortikultura, Badan Litbang Pertanian telah banyak dihasilkan. Teknologi tersebut telah di-Gelar-kan kepada kelompok-kelompok tani, bahkan kondisi dilapangan menunjukkan bahwa teknologi yang di hasilkan tersebut telah banyak diterapkan oleh beberapa kelompok tani di DKI Jakarta seperti Kelompok Wanita tani Widya Tani, Kelompok Wanita tani Ayu Lestari di Jakarta Selatan serta Kelompok Mekar Sari dan Kelompok Ganda Mekar, di Jakarta Timur.

Informasi tentang beberapa resep olahan yang dicantumkan dalam brosur ini merupakan hasil beberapa penelitian yang dilakukan oleh Pusat Penelitian dan Pengembangan Penelitian Hortikultura, Jakarta dan telah diaplikasikan oleh para petani
pengolah yang ada di DKI Jakarta. Selain dari itu modifikasi dari beberapa resep olahan
buah-buahan tersebut dilakukan oleh para petani pengolah di DKI Jakarta guna memperkaya khasanah resep dalam upaya untuk memenuhi selera masyarakat.

II. Dasar-dasar pengolahan dan pengawetan produk pertanian

Untuk mendapatkan hasil pengolahan yang baik dan kualitas yang diinginkan, diharapkan mengetahui terlebih dahulu dasar-dasar tentang pengolahan dan pengawetan produk pertanian. Hal ini akan berpengaruh pada usaha-usaha untuk memodifikasi dan mengembangkan resep-resep yang telah dihasilkan.

Teknologi pasta panen pada umumnya merupakan penerapan secara teknik dari ilmu dan mekanisasi dalam perlakuan dan pengolahan untuk mengamankan dan mempertinggi daya guna makanan berdasarkan pads ilmu kimia, fisika, biologi dan mekanisasi.

Usaha-usaha yang dilakukan oleh teknologi makanan antara lain mengubah bahan makan menjadi bentuk yang mudah dipergunakan dan lebih dimanfaatkan oleh masyarakat baik dalam harga maupun rasa; membuat bahan pangan serta hasil olahannya menjadi tahan simpan; mempertahankan atau memperbaiki nilai gizi; membantu atau mencegah terjadinya gangguan kesehatan karena makanan (sanisatasi, pengawasan, pengolahan dan mutu bahan).

Ilmu teknologi makanan tidak mengajarkan cara-cars merubah bahan makan yang busuk menjadi baik, melainkan mempertahankan yang baik (bentuk kekerasan, warna,
rasa, dan sebagainya) agar tetap baik. Teknologi makanan adalah ilmu memperlakukan
bahan makanan menjadi makanan yang harus memenuhi kepuasan mata (warna, ukuran, keseragaman, konsisten), kepuasan hidung (bau, aroma), kepuasan tangan (keras, empuk, liat, butir, tepung dan sebagainya), kepuasan lidah (cita rasa), kepuasan gizi (keras, empuk, list dan sebagainya) disamping memperbaiki gizi untuk pencukupan
kebutuhan pertumbuhan badan yang sehat, kuat dan cerdas serta pengamanan dan penyelamatan modal.

Pengawetan makanan sudah dikenal sejak berabad-abad lamanya. Mula-mula pengawetan hanya dikerjakan agar bahan makan dapat disimpan hingga waktu paceklik atau apabila produksi sangat melimpah.

Secara garis besar, pengolahan makanan dapat menjadi tiga golongan.

1.Pengawetan secara fisika
2.Pengawetan secara kimia
3.Pengawetan secara mikrobiologi

2.1.Pengawetan secara fisika
a. Cara Pendinginan
Jika suhu penyimpanan diturunkan maka bahan yang disimpan akan lebih tahan lama sebab perkembangan jasad renik dan metabolisme bahan yang disimpan akan berjalan lebih lambat.
b. Cara Pengeringan
Pada cara pengeringan kadar air bahan diturunkan sedemikian rupa sehingga enzim-enzim tidak dapat bekerja dan jasad renik tidak dapat berkembang biak. Banyaknya sisa air yang diperbolehkan adalah berbeda untuk tiap jenis bahan. Faktor faktor yang mempengaruhi antara lain kadar gula, kadar garam, lamanya penyimpanan dan sebagainya. Pads umumnya kadar air bahan makanan yang telah dikeringkan antara 1 sampai 20 %.
Pengeringan dapat dikerjakan sebagai berikut:

b.1. Pengeringan matahari / Penjemuran
Pengeringan matahari dapat dilakukan secara penjemuran sederhana dengan penghamparan di bawah sinar matahari atau dikerjakan dengan mempergunakan slat pengering tenaga tats surya. Bila perlu untuk menghindari menjadi hitamnya jaringan-jaringan sebelum dikeringkan dilakukan terlebih dahulu pembelerangan. Pemberian uap belerang dibakar (gas belerang dioksida) berjalan selama 15 menit sampai beberapa jam. Banyaknya belerang diserap dipengaruhi oleh suhu dan pendekatan belerang dioksida tersebut. Pembelerangan ini rata-rata membutuhkan 1000 sampai 3000 bagian per juts belerang dioksida yang sebagian besar akan hilang waktu proses pengeringan berikutnya.

b.2.Pengeringan buatan
Tiap butir atau tiap potong bahan makanan yang mempunyai kadar air tertentu mempunyai keseimbangan dengan kelembaban nisbi udara. Pada pengeringan buatan, sifat ini harus diperhatikan pula bahwa suhu dan lamanya pengeringan akan mempengaruhi rasa, warm, dan kekerasan bahan tersebut.

c. Pengalengan atau pembotolan
Dasar pengawetan dengan pengalengan atau pembotolan ialah bahan makanan diisikan kedalam kaleng atau botol kemudian ditutup rapat dan dipanaskan pada suhu dan selama waktu tertentu. Dengan cara ini semua jasad renik yang semula terdapat pada bahan baku dihancurkan, enzim-enzim dihentikan atau dicegah kegiatannya dan penularan kembali oleh jasad renik dari luar dihindari.

2.2. Cara kimia
a.Pengawetan dengan garam dapur
Banyaknya garam dapur yang terdapat dalam suatu bahan makanan menentukan jasad renik yang dapat berkembang biak di dalamnya. Kadar garam jugs akan mempengaruhi tingkat perubahan yang akan dicapai oleh jasad renik tersebut. Garam dapur merupakan racun untuk jasad renik dan bersama-sama dengan asam mempunyai daya rusak jasad renik. Garam dapur yang kotor mengandung banyak zat-zat lain misalnya magnesium clorida (MgCI2), Kalsium Sulfat (CaSo4), Kalsium Clorida (CaCI2) dan garam-garam lainnya. Bahan-bahan tersebut sangat mempengaruhi mudah tidaknya garam masuk kedalam bahan yang akan digarami. Kecuali itu juga mempengaruhi warna dan rasa. Karena itu dianjurkan untuk menggunakan garam yang sudah dibersihkan.

b. Pengawetan dengan asam
Bakteri pembusuk berkembang biak pada pH yang tinggi. Untuk merendahkan pH tersebut perlu ditambahkan asam, misalnya asam sitrat atau asam laktat sebanyak 1,5 – 1,8 % atau asam clorida sebanyak 0,036 – 0,072 %.

c.Pengawetan dengan karbon dioksida
Karbon dioksida banyak digunakan pada minuman-minuman penyegar misalnya coca cola, F&N, Seven-Up dan lain-lain. Karbondioksida yang digunakan untuk memperpanjang kesegaran buah yang disimpan dalam bejana tertutup.

d. Pengawetan dengan antibiotika atau bahan pengawet lainnya.
Antibiotika yang pernah digunakan sebagai bahan pengawet antara lain sulfatiazol, sulfanilamid, penicilin G, Streptomycin. Bahan pengawet makanan yang sekarang lazim dipergunakan misalnya asam benzoat dan garam-garamnya, asam sorbat dan garam-garamnya, asam para cloro-benzoat, microhin, solbrol A dengan garam-garamnya, Hexamethylene tetramine, preventol O extra atau preventol ON extra.

e. Pengawet dengan gula
Gula banyak sekali digunakan pada pengawetan makanan yang berasal dari buah-buahan. Sari buah, sirop, anggur, manisan buah, jam (selai) adalah contoh-contoh makanan awet yang banyak menggunakan gula. Gula dalam hal ini berfungsi ganda, memberi rasa manis, mempertahankan warna dan kekerasan dan menarik air dari sel-sel buah-buahan sehingga mikroba tak cocok tumbuh disana. Penggunaan gula selalu dikombinasikan misalnya dengan pengeringan, dengan bahan pengawet, canning dan fermentasi.

2.3.Pengawetan Cara Mikrobiologis
Pengawetan makanan umumnya untuk menghambat atau mencegah memperkembangbiakan mikroba. Namun kenyataannya tidak semua jasad renik merusak, beberapa jenis diantaranya bisa digunakan untuk pengawetan makanan. Produksi sejumlah asam oleh jasad renik tertentu menciptakan kondisi yang baik untuk jasad renik lainnya. Proses yang terakhir ini lazim disebut dengan peragian atau fermentasi.

Fermentasi adalah proses an-aerobic atau sebagian aerobic, suatu proses oksidasi karbohidrat. Fermentasi dibedakan dari pembusukan karena terakhir merupakan perombakan an-aerobic terhadap bahan yang mengandung protein.

Natrium Clorida / garam dapur sangat berguna pada proses fermentasi karma garam ini menghambat pertumbuhan mikroba pembusuk dan sebagian terbesar mikroba lainnya. Bakteri tertentu tahan dalam larutan garam. Contoh-contoh hash fermentasi anggur, cuka (cider), alkohol, acar dan macam-macam asinan lainnya.

III. PEMBUATAN ANEKA SARI BUAH

a.Sari buah nenas
Bahan : Buah nenas yang matang
Air masak
Gula pasir
Asam sitrat
Pewarna makanan kuning

Cara pembuatan:

  1. Buah nenas yang cukup tua dikupas kulitnya kemudian dibuang mata dan empelurnya.
  2. Dicuci bersih kemudian dihaluskan dengan cara diparut atau dihancurkan dengan alat “Waring blendor”.
  3. Sari yang diperoleh ditakar : 500 cc + 700 gram gula + asam sitrat 3 gram / liter + warna kuning.
  4. Setiap liter sari yang diperoleh dicampur dengan 3 liter air masak yang telah dingin.
  5. Dari 1 liter sari buah akan diperoleh 4 liter larutan sari buah.
  6. Setiap liter larutan sari buah ditambahkan dengan 125 gram gula pasir 1-2 gram asam sitrat tergantung pada derajat ke asaman buah nenas yang diperoleh.
  7. Diaduk-aduk terus hingga gula pasir seluruhnya hancur atau larut.
  8. Disaring dengan kain bersih atau saringan nylon yang halus.
  9. Diberi pewarna makanan yang berwarna kuning secukupnya.
  10. Dimasukkan kedalam botol yang telah dicuci bersih dan steril.
  11. Ditutup rapat dengan penutup “Crown Curk”
  12. Dipasteurisasi dengan cara merebusnya dalam panci besar pada suhu sekitar 85 °C selama I S menit.
  13. Dinginkan dan diamkan selama 2 Minggu untuk mengetahui inkubasi jasad renik. Bila dalam 2 Minggu terdapat botol berisi sari buah nenas yang rusak berarti pengawetan kurang sempurna. Sari buah nenas yang rusak tersebut dipisahkan dan sebaiknya jangan dikonsumsi atau diperdagangkan.

aneka01

Gambar 1 : Penambahan gula pasir dan asam sitrat diaduk merata

b. Sari buah jambu biji
Bahan-bahan : Buah jambu biji
Air masak
Gula pasir
Asam sitrat
Pewarna makanan

Cara Pembuatan:

  1. Buah jambu biji dipilih yang cukup matang dan tua. Dapat diplih buah jambu biji dengan daging buahnya berwarna putih ataupun yang berwarna merah. Jangan pilih buah jambu yang masih keras atau mengkal karena buah yang masih keras berarti masih muda dan rasanya masih agak sepat karma banyak mengandung zat tanin. Dan jangan pula memilih jambu biji yang telah matang sekali karena buah yang terlalu matang mengandung pectin hanya sedikit sehingga dapat mengakibatkan konsentrasi sari buahnya kurang baik.
  2. Buah dikupas kulitnya kemudian dibuang bijinya.
  3. Dicuci bersih lalu dihaluskan dengan cara diparut atau dihancurkan dengan alat “waring blendor”, kemudian di tambah air secukupnya.
  4. Sari buah yang diperoleh kemudian ditakar.
  5. Setiap liter sari buah yang diperoleh dicampur dengan 3 liter air masak yang telah dingin.
  6. Dari setiap liter sari buah jambu biji akan diperoleh 4 liter sari buah jambu biji.
  7. Setiap liter sari buah jambu biji ditambahkan 125 gram gula pasir dan 2 gram asam sitrat/ liter sari buah jambu biji berwarna menarik.
  8. Sari buah diaduk-aduk terus sehingga gula pasir seluruhnya larut.
  9. Disaring dengan saringan kain yang bersih atau dengan saringan nylon yang halus.
  10. Diberi pewarna makanan yang berwarna merah hingga warna sari buah jambu biji tersebut menjadi merah muda.
  11. Dimasukkan ke dalam botol sari buah yang bersih dan steril.
  12. Ditutup rapat dengan menggunakan “Crown Curk”.
  13. Dipasteurisasi dengan cara merebus botol yang telah berisi sari buah tersebut di dalam panci besar pada suhu sekitar 85 derajat selama IS menu.
  14. Dinginkan dan diamkan selama 2 Minggu untuk masa inkubasi jasad renik. Bila dalam waktu 2 Minggu terdapat botol yang berisi sari buah jambu biji yang rusak sebaiknya dipisahkan dan jangan dikonsumsi atau diperdagangkan.

aneka02Gambar 2 : Penutupan botol dengan rapat menggunakan alat pres

c. Pembuatan Sari Buah Sirsak
Bahan-bahan : Buah sirsak
Air masak
Gula pasir
Asam sitrat
Pewarna makanan

Cara Pembuatan :

  1. Buah sirsak dipilih yang telah matang (empuk). Sebaiknya jangan dipili) buah sirsak yang matangnya karena diperam karbit karma buah sirsak yang telah diperam dengan karbit rasanya sedikit kurang enak dan kadang-kadang dapat mengakibatkan botol pecah pada waktu pasteurisasi.
  2. Buah dikupas kemudian dibuang biji dan empelurnya.
  3. Buah diambil dagingnya saja kemudian dihaluskan dengan cara dihaluskan dengan cara digerus diatas ayakan bambu atau dihancurkan dengan alat waring blendor.
  4. Sari buah yang telah diperoleh kemudian ditakar.
  5. Setiap liter sari buah yang diperoleh dicampur dengan 4 liter air masak yang telah dingin.
  6. Dari satu liter sari buah sirsak akan diperoleh 5 liter larutan sari buah.
  7. Setiap larutan sari buah ditambah dengan 150 gram gula pasir dan 1 gram asam sitrat.
  8. Larutan diaduk-aduk terus hingga gula pasir yang ditambahkan menjadi larut semuanya.
  9. Disaring dengan menggunakan saringan kain yang bersih atau dengan saringan nylon yang halus.
  10. Dapat diberi pewarna makanan yang berwarna hijau hingga warna asli buah tersebut menjadi hijau muda.
  11. Dimasukkan ke dalam botol sari buah yang telah bersih dan steril.
  12. Ditutup rapat dengan penutup “Crown Curk”
  13. Dipasteurisasi dengan cara merebus botol yang telah berisi sari buah tersebut di dalam panci besar pada suhu sekitar 85 °C selama 15 menit.
  14. Dinginkan dan diamkan selama 2 Minggu untuk inkubasi jasad renik. Bila dalam waktu 2 Minggu terdapat botol yang berisi sari buah yang rusak sebaiknya dipisahkan dan jangan dikonsumsi atau diperdagangkan.

d. Pembuatan Sari buah campuran sirsak dan nangka
Bahan-bahan : Buah sirsak
Buah nangka
Air masak
Gula pasir
Asam sitrat
Natrium benzoat

Cara Pembuatan :

  1. Buah sirsak dipilih yang telah matang (empuk), buah nangka juga dipilih yang telah matang.
  2. Kedua macam buah dikupas kulitnya dan diambil bagian buahnya saja.
  3. Masing-masing daging buah dihaluskan secara terpisah. Caranya dengan digerus diatas ayakan bambu atau dihancurkan dengan alat waring blendor.
  4. Sari buah masing-masing buah ditakar secara terpisah.
  5. Setiap liter sari buah sirsak di campur dengan 4 liter air masak yang telah dingin dan setiap liter sari buah nangka dicampur dengan 4 liter air yang serupa.
  6. Dari 1 liter sari buah masing-masing akan diperoleh 5 liter larutan sari buah.
  7. Setiap liter larutan sari buah sirsak ditambah 150 gram gula pasir dan 1 gram asam sitrat sedangkan setiap liter sari buah nangka ditambahkan 125 gram gula pasir dan 3 gram asam sitrat.
  8. Masing-masing sari buah di aduk-aduk terus hingga gula pasir larut seluruhnya.
  9. Masing-masing sari buah disaring dengan menggunakan saringan kain yang bersih atau saringan nylon yang halus.
  10. sari buah yang diperoleh dicampur dengan sari buah nangka yang diperoleh dengan perbandingan 1:1 sehingga diperoleh sari sirka (sirsak dan nangka). Sari sirka yang diperoleh perlu ditambah Natrium Benzoat sebanyak ½ gram untuk setiap liter sari buah sirka tadi karena sari buah ini termasuk salah satu jenis sari buah yang sangat mudah rusak.
  11. sari buah sirka dimasukan kedalam botol yang telah bersih dan steril.
  12. ditutup dengan penutup “crown curk” agar rapat benar.
  13. Dipasteurisasi pada suhu sekitar 80 oC selama 15 menit.
  14. Di inkubasi setelah dingin dengan cara disimpan selama 2 minggu.

e. Pembuatan Sari Buah Belimbing
Bahan-bahan : Buah Belimbing
Air masak
Gula pasir
Asam sitrat
Natrium benzoat

aneka03Gambar 3: Belimbing yang telah dicuci bersih dipotong memanjang

Cara Pembuatan :

  1. Pilih buah Belimbing yang telah matang penuh. Usahakan memilih varietas Belimbing yang sama seperti varietas Dewi, Paris, Bangkok, Demak, dll.
  2. Belimbing yang telah dipilih cuci sampai bersih.
  3. Dipotong memanjang sesuai dengan bilah belimbing yang ada.
  4. Belimbing yang telah dipotong, dikukus selama 5 sampai dengan 10 menit.
  5. Setelah layu semuanya belimbing dihancurkan dengan menggunakan penghancur atau blender sehingga menjadi bubur belimbing.
  6. Dilakukan pengenceran bubur belimbing dengan menambahkan air 1 liter bubur belimbing dicampur dengan 3 liter air matang.
  7. Setelah itu dilakukan penyaringan dengan kain kasa atau penyaring dari nylon yang bersih.
  8. Setiap liter larutan sari buah ditambah dengan 150 gram gala pasir dan 2 gram asam sitrat.
  9. Larutan diaduk-aduk terus hingga gula pasir yang di tambah kan menjadi larut semuanya.
  10. Disaring dengan menggunakan saringan kain yang bersih atau dengan saringan nylon yang halus.
  11. Dimasukkan kedalam botol sari buah yang telah bersih dan steril.
  12. Ditutup rapat dengan penutup “Crown Cruk”.
  13. Dipasteurisasi dengan cara merebus botol yang telah berisi sari buah tersebut di dalam panci besar pada suhu sekitar 85 °C selama 30 menit.
  14. Dinginkan dan diamkan selama 2 Minggu untuk inkubasi jasad renik. Bila dalam waktu 2 Minggu terdapat botol yang berisi sari buah yang rusak sebaiknya dipisahkan dan jangan dikonsumsi atau diperdagangkan.

aneka04Gambar 4: Proses pasteurisasi dengan cara merebus botol selama 30 menit

f. Pembuatan sari buah pisang
Bahan-bahan : Buah pisang
Asam sitrat
Gula pasir

Cara Pembuatan

  1. Buah harus dipilih yang matang penuh dan tidak busuk, dicuci dengan air bersih, kemudian dikupas dan dibuang kulitnya.
  2. Daging buah direndam dalam larutan asam sitrat 0,4 % agar tidak terjadi pencoklatan pads daging buah.
  3. Setelah ditiriskan kukus dengan dandang selama 7 menit dihitung saat air mendidih.
  4. Setelah dikukus, buah dihancurkan untuk mendapatkan sari buahnya. Untuk ekstraksi sari buah dapat ditambahkan air dengan perbandingan 1 bagian sari buah dengan 3 bagian air.
  5. Kemudian disaring, hasil saringan tersebut ditambahkan gula sebanyak 125 gram – 150 gram per liter sari buah yang di dapat. Lalu ditambahkan 1 – 2 gram asam sitrat.
  6. Siapkan botol yang telah bersih dan steril.
  7. Masukkan sari buah yang telah jadi, lalu tutup botol yang rapat dengan menggunakan crown curk.
  8. Lakukan pasteurisasi dengan merebus botol yang telah berisi sari buah yang telah berisi sari buah pisang selama 30 menit. Lalu dinginkan.

aneka05Gambar 5: Penyaringan sari buah dengan menggunakan kain kasa

aneka06Gambar 6: Penambahan untuk sari buah

IV. PEMBUATAN ANEKA JAM

Bahan-bahan :
Buah nenas, Belimbing wuluh
Jambu biji, Sirsak, dll.
Gula pasir
Asam sitrat
Natrium benzoat.

Cara Pembuatan

  1. Buah dipilih yang cukup tingkat ketuaannya. Nenas dan sirsak sebaiknya dipilih yang telah matang. Belimbing wuluh dan jambu sebaiknya jangan dipilih yang terlalu tua karena buah yang terlalu tua kadar pektin yang dikandung oleh buah mempengaruhi tekstur jam yang akan dihasilkan.
  2. Buah dibersihkan dan diambil bagian daging buahnya saja.
  3. Kemudian buah dihaluskan dengan cara digerus diatas ayakan bambu atau dihancurkan dengan alat waring blendor.
  4. Buah yang terlalu banyak mengandung air seperti misalnya nenas Palembang atau belimbing wuluh sebaiknya sebagian air buahnya dibuang dengan cars menyaring air buah yang telah dihaluskan tersebut. Membuangnyapun jangan terlalu banyak.
  5. Sari buah yang diperoleh kemudian ditakar.
  6. Sari buah dipanaskan selama 15 menit.
  7. Ditambahkan gula pasir dan asam sitrat. Untuk setiap liter sari buah diperlukan 1 Kg gala pasir dan 5 gram asam sitrat. Jika buah yang dipergunakan rasanya asam cukup tambahkan 3 gram asam sitrat.
  8. Dipanaskan terus menerus diatas api sambil diaduk-aduk secara merata sampai sari buah tersebut mengental. Untuk mengetahui apakah jam tersebut cukup mengental ambillah sebuah piring dan letakkan diatas piring. Jika piring dimiringkan dan ternyata jam tidak meleleh hal tersebut menandakan bahwa jam tersebut sudah cukup kekentalannya. Tambahkan Natrium benzoat I/2 gram untuk setiap liter.
  9. Sewaktu masih panas masukkan kedalam botol yang telah bersih dan steril, kemudian ditutup rapat-rapat.
  10. Botol yang telah berisi jam tersebut dikukus dengan suhu 100 °C selama 30 menit.
  11. Untuk jam buah-buahan dapat pula diberikan zat pewarna makanan agar lebih menarik penampilannya.

V. PEMBUATAN ANEKA SIROP

a. Pembuatan Sirop Temu Lawak
Bahan-bahan :
Gula pasir 2 Kg
Temu Lawak 100 gram
Asam sitrat 3 gram
Bunga pala 1 gram
Kayu manis 1 gram
Cengkeh tanpa kepala 1/2 gram
Air 11/2 liter

Cara Pembuatan

  1. Temu lawak yang telah dikeringkan dicampur dengan bunga pala, kayu manis dan cengkeh yang telah dibuang kepalanya.
  2. Ditambahkan air kemudian dimasak sehingga air tinggal 1 liter. Selama memasaknya diaduk-aduk terus.
  3. Diamkan selama 1 malam.
  4. Disaring untuk diambil ekstrak rebusan campuran tersebut.
  5. Ekstrak campuran ini ditambah gula pasir kemudian di masak sambil diaduk-aduk hingga gula seluruhnya larut.
  6. Disaring dengan saringan kain yang bersih kemudian ditambahkan asam sitrat.
  7. Sewaktu masih panas masukkan kedalam botol yang telah bersih dan steril, kemudian tutup rapat-rapat dengan penutup crown curk.

b. Pembuatan Sirop Jahe
Bahan-bahan :
Jahe 1 Kg
Air masak 10 liter
Gala 12 Kg

Cara Pembuatan

  1. Jahe dibersihkan dari kotoran yang menempel.
  2. Jahe diparut dengan menggunakan parutan, dan direbus dengan 2 liter air selama 30 menit.
  3. Dinginkan sejenak baru diperas dan disaring dengan menggunakan kain kasa atau saringan nylon.
  4. Kemudian sari jahe tersebut ditambahkn 8 liter air.
  5. Kemudian direbus, setelah mendidih masukkan 12 Kg gala lalu diaduk-aduk selama 30 menit, lalu dinginkan.
  6. Siapkan botol yang bersih dan steril, masukkan kedalam botol yang bersih dan steril, masukkan sirop jahe yang telah dingin.
  7. Sterilisasi selama 15 hari.

Ampas jahe yang diperas tadi dapat digunakan untuk membuat enting-enting jahe

Caranya Pembuatan :

  1. Ampas jahe ditumbuk sampai halus.
  2. Siapkan gala merah sebanyak 3/4 Kg dan gala pasir 1l4 Kg kemudian larutkan.
  3. Setelah itu masukkan ampas jahe yang telah ditumbuk tadi.
  4. Aduk- aduk hingga merata diatas api kecil pelan 30 menit.
  5. Setelah itu diangin-anginkan di atas tampah lalu dipotong potong sesuai dengan keinginan.

VI. PEMBUATAN ANEKA CORDIAL

a. Pembuatan Cordial Jeruk Nipis
Bahan-bahan :
Jeruk nipis
Natrium metabisulfit
Natrium benzoat
Gula pasir
Pewarna makanan

Cara Pembuatan

  1. Jeruk nipis dipilih yang baik mutunya kemudian dicuci bersih.
  2. Dibelah atau diiris dan selanjutnya diperas untuk ambil sarinya.
  3. Sari buah yang diperoleh ditakar.
  4. Ditambahkan natrium metabisulfit sebanyak 2 gram untuk setiap liter sari buah jeruk nipis yang dihasilkan.
  5. Dibiarkan mengendap partikel-partikelnya yang banyak mengandung zat limonie. Zat ini dapat mengakibatkan rasa pahit terutama bila kena panas.
  6. Pengendapan berlangsung 2 malam.
  7. Setelah 2 malam sari buah jeruk nipis akan memisah menjadi 2 bagian sari buah yang bening dan bagian sari buah yang keruh.
  8. Pisahkan bagian sari buah yang bening dengan hati-hati.
  9. Setiap liter sari buah yang bening dicampur dengan 3 liter air hangat dan 8 Kg gula pasir sambil diaduk secara terus menerus hingga gula pasir larut seluruhnya.
  10. Disaring dengan saringan kain yang bersih.
  11. Ditambahkan Natrium benzoat sebanyak 1/2 gram untuk setiap cordial.
  12. Masukkan kedalam botol yang telah bersih dan steril kemudian tutup rapat-rapat dengan penutup.

b. Pembuatan Cordial Belimbing Wuluh
Bahan-bahan :
Buah belimbing wuluh yang cukup tua
Gula pasir
Natrium benzoat
Essence jeruk (bila diperlukan)
Pewarna makanan

Cara Pembuatan

  1. Buah belimbing wuluh atau belimbing sayur dipilih yang cukup tingkat ketuaannya, jangan dipilih yang masih muda atau yang sudah tua.
  2. Dibersihkan bagian ujung dan pangkal kemudian dicuci bersih. Selanjutnya bijinya dibuang.
  3. Dihaluskan dengan cara digerus diatas ayakan bambu atau dengan alat waving blendor disaring lalu diambil sarinya.
  4. Ditambahkan gula pasir sebanyak 1,5 Kg untuk setiap liter sari buah.
  5. Dimasak sampai mendidih sambil diaduk-aduk terus agar gula larut seluruhnya lalu tambahkan Natrium benzoat sebanyak 1/2 gram untuk setiap liter cordial.
  6. Masukkan kedalam botol steril dan tutup rapat.

DAFTAR PUSTAKA

  1. Anonimous, 1988. Penanganan Pasca Panen dan Pengawetan Hasil Pertanian. Dinas Pertanian DKI Jakarta.
  2. Syoaib, Sri Yunani, 1988. Mengolah Makanan dan Minuman Awet. Kelompok Wanitatani Tani Ganda Mekar.
  3. Syoaib, Sri Yunani, 1988. Manfaat Pemasaran Manisan Daun Pepaya Bagi Masyarakat Serta Anggota Kelompok Wanitani.
  4. Maharani, 1991. Pengolaahan Pasca Panen
  5. Nuraisin, 1996. Potensi, Peluang dan Kendala Agribisnis Kelompok Petani Perkotaan.




Resource Description Framework (RDF)

3 08 2009

RDF Tulang Punggung Web 3.0 / Semantic Web

Oleh : Teguh Sutopo

1. SEJARAH DAN PERKEMBANGAN WEB

Website atau juga disebut dengan WORLD WIDE WEB (WWW) lahir di tahun 1989 ketika seorang peneliti CERN (pusat penelitian nuklir Eropa) bernama Tim Berners-Lee membuat sebuah browser berbasis hyperlink untuk sistem pengakses tulisan ilmiah di lembaga tersebut. Browser yang sangat sederhana itu pertama diberi nama WorldWideWeb, tanpa spasi, lalu kemudian berganti menjadi Nexus untuk menghindari kerancuan dengan istilah WWW. Walaupun sekarang WWW sudah meraih sukses besar melebihi perkiraan pembuatnya di awal pembuatannya.


Website sejak pemunculannya telah mengalami perkembangan yang sangat pesat. Secara fungsional Website digunakan untuk melakukan transaksi, penyebaran informasi, maupun pencarian informasi. Website yang memiliki mesin pencari informasi seperti altavista, google, yahoo, cuil, wolframalpha, dan yang terbaru bing telah menjadi alternatif utama bagi masyarakat dalam mencari berita atau informasi.


Secara teknologi, Website sampai saat ini memasuki generasi ke 3 yaitu Web 3.0 atau disebut semantic web yang meskipun masih dalam perdebatan para analis dan peneliti untuk standarisasi.

Adapun generasi website yang sudah ada dan masih berjalan yaitu Web 1.0 dan Web 2.0. Secara ringkas mengenai Web tersebut adalah sebagai berikut :

Web 1.0

Web 1.0 merupakan teknologi Web generasi pertama yang merupakan revolusi baru di dunia Internet karena telah mengubah cara kerja dunia industri dan media. Pada dasarnya, Website yang dibangun pada generasi pertama ini secara umum dikembangkan untuk pengaksesan informasi dan memiliki sifat yang sedikit interaktif namun cenderung pasif. Berbagai Website seperti situs berita “cnn.com” atau situs belanja “Bhinneka.com” dapat dikategorikan ke dalam jenis ini.

Web 2.0

Istilah Web 2.0 pertama kalinya diperkenalkan oleh O’Reilly Media pada tahun 2004 sebagai teknologi Web generasi kedua yang mengedepankan kolaborasi dan sharing informasi secara online.

Menurut Tim O’Reilly, Web 2.0 dapat didefinisikan sebagai berikut:

Web 2.0 adalah revolusi bisnis di industri komputer yang disebabkan oleh penggunaan internet sebagai platform, dan merupakan suatu percobaan untuk memahami berbagai aturan untuk mencapai keberhasilan pada platform baru tersebut. Salah satu aturan terutama adalah: Membangun aplikasi yang

mengeksploitasi efek jaringan untuk mendapatkan lebih banyak lagi pengguna aplikasi tersebut

Berbagai layanan berbasis web seperti jejaring sosial, wiki dan folksonomies (misalnya: “flickr.com”, “del.icio.us”) merupakan teknologi Web 2.0 yang menambah interaktifitas di antara para pengguna Web.

Pada umumnya, Website yang dibangun dengan menggunakan teknologi Web 2.0 memiliki fitur-fitur sebagai berikut:

  • CSS (Cascading Style Sheets)

  • Aplikasi Rich Internet atau berbasis Ajax

  • Markup XHTML

  • Sindikasi dan agregasi data menggunakan RSS/Atom

  • URL yang valid

  • Folksonomies

  • Aplikasi wiki pada sebagian atau seluruh Website

  • XML Web-Service API

Web 3.0 / Semantic Web

Web 3.0 berpotensi menjadi generasi teknologi di dunia Internet. Saat ini, definisi untuk Web 3.0 sangat beragam mulai dari pengaksesan broadband secara mobile sampai kepada layanan Web berisikan perangkat lunak bersifat on-demand. Namun, menurut John Markoff, Web 3.0 adalah sekumpulan teknologi yang menawarkan cara baru yang efisien dalam membantu komputer mengorganisasi dan menarik kesimpulan dari data online. Content web ditampilkan tidak hanya dalam format bahasa manusia yang umum (natural language), tetapi juga dalam format yang dapat dibaca dan digunakan oleh mesin (baca: software).

Melalui Semantic Web inilah, berbagai perangkat lunak akan mampu mencari, membagi, dan mengintegrasikan informasi dengan cara yang lebih mudah. Dengan demikian, unsur kecerdasan buatan (Artificial Intelligence / AI) merupakan bagian penting pada Web 3.0 / Semantic Web, sehingga Web menjadi semakin cerdas.


2. Komponen-komponen Semantic Web

Pembuatan Semantic Web dimungkinkan dengan adanya sekumpulan standar yang dikoordinasi oleh World Wide Web Consortium (W3C). Standar yang paling penting dalam membangun Semantic Web adalah XML, XML Schema, RDF, OWL, dan SPARQL.

Berikut ini adalah layer dari Semantic Web sebagaimana direkomendasikan oleh W3C (www.w3c.org):

gmb1_RDF

Gambar 1: Layer pada Semantic Web


3. Resource Description Framework (RDF)

Salah satu tulang punggung Web 3.0 adalah format dan spesifikasi yang memungkinkan komunikasi dan interaksi pada level mesin, W3C mendefinisikan format metadata yang dikenal dengan RDF (Resource Description Format). RDF terdiri dari tiga komposisi, meliputi subject, predicate, dan object. Predicate merupakan komposisi yang menerangkan sudut pandang dari subject yang dijelaskan object, sementara subject dan object merupakan entitas. Object di dalam RDF dapat menjadi subject yang diterangkan oleh object yang lainnya. Dengan inilah object dapat berupa masukan yang dapat diterangkan secara jelas dan detail, sesuai dengan keinginan pengguna yang memberikan masukan.

Cara kerja RDF dapat diterangkan dengan satu contoh sederhana berikut, untuk mendefinisikan “daun memiliki warna hijau”, maka “daun” direpresentasikan sebagai subject, “hijau” merupakan object, dan “memiliki warna” adalah predicate. Dengan menggunakan RDF, website dapat menyimpan dan melakukan pertukaran informasi antar-web. RDF telah digunakan pada aplikasi-aplikasi, antara lain:

a. RSS (RDF Site Summary).

RSS memberikan informasi update sebuah website tanpa pengunjung perlu mengunjungi website tersebut.

b. FOAF (Friend of a Friend).

Didesain untuk mendeskripsikan orang-orang, ketertarikan dan hubungan mereka.

c. SIOC (Semantically-Interlinked Online Communities).

Menerangkan komunitas online dan menciptakan koneksi antara diskusi berbasis Internet seperti message board, blog, maupun mailing list.

Dasar RDF

Sebagai sebuah standar bahasa semantik web yang ditetapkan oleh W3C, RDF merupakan suatu pondasi dalam melakukan pemrosesan metadata. Di dalam RDF berlaku aturan “seseorang dapat mengatakan apapun mengenai apapun dimanapun”. Ini berarti bahwa hubungan antara 2 obyek dapat berada di beberapa dokumen yang terpisah dari obyeknya, sehingga tidak diperlukan obyek secara fisik untuk menjelaskan deskripsinya, melainkan menggunakan referensi yang mengacu kepada obyek tersebut.

Elemen dasar model RDF adalah triple atau statements : berupa sebuah resource (subyek) yang dihubungkan dengan resource yang lain atau literal (obyek) melalui resource ketiga (predikat). Resource ini diidentifikasi dengan URI. Sebuah statement dapat didefinisikan : mempunyai property bernilai.


Adapun tujuan dari desain RDF3 adalah untuk memenuhi kriteria berikut :

  1. Memiliki model data yang sederhana

  2. Memiliki bentuk semantic yang formal dan inference yang dapat dibuktikan

  3. Menggunakan extensible URI-based vocabulary

  4. Menggunakan sintaks XML

  5. Mendukung penggunaan XML Schema Datatypes

  6. Memperbolehkan setiap orang untuk mendefinisikan tentang resource


RDF Schema

RDF Schema adalah vocabulary yang digunakan untuk membuat RDF. Terdapat tiga konsep penting dalam RDF Schema, yaitu Resource (rdfs:Resource), Class (rdfs:Class), Property (rdf:Property).


Apabila ingin menjelaskan sesuatu adalah “type” dari sesuatu yang lain, dapat menggunakan rdf:Type Property:-. Contoh berikut akan memperjelas:


rdfs:Resource rdf:type rdfs:Class.

rdfs:Class rdf:type rdfs:Class.

rdf:Property rdf:type rdfs:Class.

rdf:type rdf:type rdf:Property.


Contoh diatas menjelaskan bahwa : Resource adalah type dari Class, Class adalah type dari Class, Property adalah type dari Class dan Type adalah type dari Property.


Untuk membuat Class sangatlah mudah. Contohnya membuat class dengan nama history:


:history rdf:type rdfs:Class


Jika ingin menjelaskan bahwa hiroshima adalah jenis history, maka:

:hiroshima rdf:type :history


Membuat property pun cukup mudah, hanya dengan menggunakan rdf:Property, seperti berikut:


:title rdf:type rdf:Property

:hiroshima :title “Hiroshima and Nagasaki”


Mengapa dikatakan Hiroshima title adalah “Hiroshima and Nagasaki”? karena :hiroshima adalah URI, dan penggunaannya dapat dilakukan dengan memilih sembarang URI, contohnya “bom_hiroshima” ataupun “hiroshima_rata”. Pertimbangan menggunakan :hiroshima terlebih kepada kemudahan dalam mengingat.


Selain tiga konsep diatas, terdapat juga rdfs:subClassOf dan rdfs:subPropertyOf, yang menjelaskan bahwa class atau property merupakan sub class atau sub property dari class atau property yang lain. Jika history adalah sub class dari documenter, maka penulisannya adalah :


:history rfds:subClassOf :documenter

Hal ini menjelaskan bahwa hiroshima adalah history, dan juga menjelaskan bahwa hiroshima adalah documenter. Penulisan sub class lain adalah sebagai berikut:


:war rdfs:subClassOf :documenter

:flora_fauna rdfs:subClassOf :documenter

Dan kemudian menciptakan instance dari class, seperti berikut:


:world_war_1 rdf:type :war

:pinus_garden rdf:type :flora_fauna


Konsep berikutnya, yang juga penting adalah domains dan ranges. Domains adalah acuan dari subyek atau obyek, sedangkan ranges adalah batasan nilai. Contohnya apabila kita ingin mengatakan bahwa properti “:duration” selalu mengacu ke video dan memiliki nilai literal, maka:


:video rdf:type rdfs:Class

:duration rdf:type rdf:property

:duration rdfs:domain :video

:duration rdfs:range rdfs:literal

:spiderman3 rdf:type :video

:video :spiderman3 “2 jam 30 menit”


Konsep lain yang ada yaitu rdfs:comment dan rdfs:label, contohnya sebagai berikut:


:spiderman3 rdfs:label “Hot Movies on May

:spiderman3 rdfs:comment “Spiderman VS Sand Man”

  1. Jena: Framework Pengembangan Aplikasi Semantic Web Berbasis Java

Jena Java RDF API and toolkit merupakan framework berbasis bahasa Java untuk mengkonstruksi aplikasi Semantic Web. Framework ini menyediakan lingkungan pemrograman untuk RDF, RDF Schema, OWL, dan SPARQL serta memiliki mesin inferensi berbasis aturan (rule-based inference engine). Jena juga memiliki kemampuan untuk digunakan sebagai basis data RDF melalui layer yang dikenal dengan nama Joseki.

Untuk membuat aplikasi Semantic Web, pertama-tama kita harus membuat model RDF.

Sebagai contoh, kita membuat model pohon keluarga sebagai berikut:

gmb2_RDF

Untuk contoh ini, misalnya kita telah memiliki vocabulary “Relationship” yang didalamnya terdapat properties siblingOf, spouseOf, parentOf, dan childOf.

Jena memiliki kelas ModelFactory yang dapat digunakan untuk membuat berbagai model. Melalui model inilah kita akan membuat sebuah Resource yang merepresentasikan setiap orang yang ada pada pohon keluarga di atas.

Setelah semua resource dibuat, selanjutnya kita dapat menambahkan statements kepada resource tersebut. Pada Jena, subjek setiap statement selalu berupa sebuah Resource, sedangkan predikat direpresentasikan oleh Property, dan objek bisa direpresentasikan oleh sebuah Resource lain maupun sebuah nilai literal.

Untuk menggambarkan relasi pada pohon keluarga tersebut, kita harus menambahkan empat buah instance Property dengan cara memanggil method addProperty( ).

Berikut ini adalah potongan kode yang merepresentasikan model pohon keluarga (keluarga.rdf) tersebut di atas.

// URI declaration

String familyUri = “http://family/”;

String relationshipUri =

http://purl.org/vocab/relationship/”;

// Create an empty Model

Model model = ModelFactory.createDefaultModel();

// Create a Resource for each family member,

// identified by their URI

Resource iwan = model.createResource(familyUri+”iwan”);

Resource santi = model.createResource(familyUri+”santi”);

Resource joni = model.createResource(familyUri+”joni”);

Resource anni = model.createResource(familyUri+”anni”);

// and so on for other family members

// Create properties for the different types of

// relationship

// to represent

Property childOf =

model.createProperty(relationshipUri,”childOf”);

Property parentOf =

model.createProperty(relationshipUri,”parentOf”);

Property siblingOf =

model.createProperty(relationshipUri,”siblingOf”);

Property spouseOf =

model.createProperty(relationshipUri,”spouseOf”);

// Add properties to iwan describing relationships to

// other family

// members

iwan.addProperty(siblingOf,santi);

iwan.addProperty(spouseOf,anni);

iwan.addProperty(parentOf,edo);

// Can also create statements directly . . .

Statement statement =

model.createStatement(iwan,parentOf,fanny);

// but remember to add the created statement to the model

    4. Kesimpulan
    RDF merupakan salah satu bagian penting Teknologi Web 3.0 / Semantic Web sehingga menjadikan Web memiliki kecerdasan (artificial intelligence / AI). Artinya, dengan menggunakan Semantic Web, informasi yang tertulis pada sebuah Website tidak saja berguna sebagai informasi yang bisa dibaca oleh manusia melainkan juga menjadi sumber informasi yang bisa diproses dan dimengerti oleh komputer.

    Tak ada gading yang tak retak, meskipun Semantic Web dipercaya sebagai generasi yang akan datang di dunia Web, berbagai kritikan juga mulai muncul. Misalnya, sejauh mana tingkat fisibilitas khususnya di dunia bisnis. Selain itu, masalah lamanya waktu saat membuat dan mempublikasi isi Web pun masih menjadi perdebatan karena untuk menampilkan sebuah informasi saja akan diperlukan dua format yang berbeda yaitu untuk dilihat manusia dan sekaligus untuk diproses mesin.

    Akhirnya, menjadikan Web 3.0 sebagai web masa depan merupakan sebuah tantangan, sebab pada dasarnya tidak ada orang yang dapat memastikan teknik pengorganisasian informasi apa yang paling tepat, mengingat data digital seluruh dunia yang begitu besar di dalam Web, yang tidak mungkin menampungnya hanya dalam sebuah framework. Namun demikian Semantic Web menawarkan sebuah solusi yang memang luar biasa bagi pemrosesan informasi di Web.

    Referensi

    1. Dave Beckett, Jeen Broekstra (2007). SPARQL Query Results XML Format. Diakses dari: http://www.w3.org/TR/rdf-sparql-XMLres/.
    2. Ian Davis, Eric Vitiello Jr. (2005). RELATIONSHIP: A vocabulary for describing relationships between people. Diakses dari: http://vocab.org/relationship/.
    3. Jeroen Van Der Ham (2007). Semantic Web Tools. Diakses dari: http://esw.w3.org/topic/SemanticWebTools.
    4. John Borland (2007). A Smarter Web. Diakses dari: http://www.technologyreview.com/Infotech/18396/.
    5. Leigh Dodds (2005). Introducing SPARQL: Querying the Semantic Web. Diakses dari: http://www.xml.com/lpt/a/1628.
    6. Ken Varnum (2007). Introduction to RDF. Diakses dari: http://www.slideshare.net/ rdf-overview-presentation4617.ppt
    7. Joko Nurjadi (2009). Menguak Kecerdasan Search Engine. PCMedia Vol. 08/2009
    8. ______. RDF Specification (technical). Diakses dari: http://www.w3.org/RDF/





    ONTOLOGI KONSEP BAHASA WEB 3.0

    3 08 2009

    Oleh : Teguh Sutopo

    1. ONTOLOGI

    Pada Yunani kuno terdapat pertanyaan: “apa inti dari hal-hal melalui perubahan?” Berbagai jawaban atas pertanyaan ini telah diajukan oleh filosof Yunani, dari Parmenides of Elea (abad keempat dan kelima), pendahulu dari ontologi, ke Aristoteles, penulis metafisika (suatu pekerjaan yang mungkin juga telah disebut ontologi).


    Dalam kajian terhadap inti dari sesuatu, Aristoteles membedakan menjadi modus yang berbeda untuk membentuk sebuah kategori suatu sistem (substansi, kualitas, kuantitas, hubungan, tindakan, gairah, tempat dan waktu) untuk mengklasifikasikan sesuatu yang mungkin diprediksi (katakan) tentang sesuatu di dunia. Misalnya, ketika kita mengatakan “komputer ini di atas meja” kita asumsikan sebagai modus berbeda dengan ketika kita mengatakan “komputer ini adalah abu-abu”. Pernyataan pertama adalah klasifikasi dalam kategori tempat, sedangkan pernyataan kedua adalah dalam kategori berkualitas. Kategorisasi yang diusulkan oleh Aristoteles telah diterima secara luas hingga abad kedelapanbelas.

    Di zaman modern, Emmanuel Kant ( 1724-1804) yang diprovokasi suatu Copernican turn. Inti sari hal tersebut ditentukan tidak hanya oleh berbagai hal diri mereka, tetapi juga oleh kontribusi dari siapapun merasa dan memahami mereka. Menurut Kant, suatu pertanyaan kunci adalah ” struktur pikiran apa yang kita gunakan untuk menangkap kenyataan itu?” Jawaban bagi pertanyaan ini menuntun ke arah penggolongan Kant. Kerangka Kant adalah mengorganisir ke dalam empat kelas, masing-masing dimana terdapat suatu pola triadic: kwantitas (kesatuan, pluralitas, totalitas), kwalitas (kenyataan, peniadaan, pembatasan), hubungan (perpaduan, sebab akibat, komunitas) dan cara sesuatu dilakukan (kemungkinan, keberadaan, keperluan). Oleh karena itu, pikiran kita menggolongkan obyek John sebagai hal yang unik, riil, ada, dan lain lain.

    Suatu penggolongan dari kategori, seperti yang tersebut di atas, dikenal sebagai suatu ontologi oleh ahli filsafat. Contoh yang paling modern tentang ontologi (dalam konteks filosofi) adalah dalam kaitan dengan Chisholm, Johanson, dan Hoffman dan Rosenkrantz, di antaranya.

    Menurut apa yang kita katakan, itu adalah sangat penting untuk dipertimbangkan bahwa ‘suatu ontologi’ tidaklah sama halnya ‘ontologi’. ‘suatu ontologi’ adalah suatu penggolongan dari kategori, sedangkan ‘ontologi’ adalah suatu cabang dari filosofi.

    Untuk menjawab pertanyaan kedua kita (“apa yang dimaksud dengan ontologi untuk ahli ontologi?”), kita dapat berasumsi bahwa ada suatu kesamaan antara kenyataan yang dirasa oleh orang-orang dan oleh komputer, dan kedua-duanya tersusun dalam ontologi. Sesuai dengan gagasan ini, jika suatu komputer adalah eksklusif untuk menjawab pertanyaan pada perjalanan, kenyataan nya bisa jadilah tersusun dengan penggolongan perjalanan ketika bepergian dengan kereta api, bepergian dengan wahana, dan lain lain. Bagaimanapun, untuk penggolongan ini realitas suatu ontologi bagi komputer, komputer harus mampu untuk meyakinkan itu. Ini mengarahkan ke perbedaan yang penting antara suatu ontologi dari segi pandangan filosofis dan dari segi pandang ilmu pengetahuan komputer. Menurut yang belakangan, suatu ontologi harus disusun dalam intepreter bahasa mesin. Dengan kata lain, ketika seorang ahli ontologi menggambarkan apa itu ontologi , dia berubah perspektif dari orang ke komputer. Seperti itu, jika komputer tidak ‘ memahami’ ontologi, komputer tidak bisa ontologi nya. Lebih dari itu, dari segi pandangan ilmu pengetahuan komputer, suatu ontologi adalah pada umumnya (walaupun tidak harus) lebih spesifik dibanding suatu ontologi dari pendekatan yang filosofis. Akhirnya, dalam kaitan dengan penggunaan dari istilah ‘ontologi’, utamanya dari reusabilas dan shareabilas menjadi penting definisi dari istilah ini untuk seorang ahli. Meskipun demikian, keutamaan seperti itu tidaklah penting dalam ontologi secara filosofis [8].

    a. Definisi

    Dari sisi pengertian terdapat beberapa difinisi yang dikemukakan oleh para pakar mengenai ontologi, yaitu [3][4][5]:

    • Neches dan rekan, “Sebuah ontologi merupakan definisi dari pengertian dasar dan relasi vocabulari dari sebuah area sebagaimana aturan dari kombinasi istilah dan relasi untuk mendefinisikan vokabulari”.

    • Gruber, “Ontologi merupakan sebuah spesifikasi eksplisit dari konseptualisme”.

    • Borst, “Sebuah ontologi adalah spesifikasi formal dari sebuah konseptual yang diterima (share)”.

    • Studer, “Konseptualisasi mengacu kepada sebuah model abstrak dari beberapa fenomena di dunia dengan memiliki identifikasi konsep yang relevan dari fenomena tersebut. Yang dimaksud dengan eksplisit adalah tipe dari konsep yang digunakan, dan batasan dari eksplisit yang digunakan. Shared adalah merefleksikan bahwa sebuah ontologi mencoba menangkap pengetahuan secara konsensus yang tidak merupakan hal yang hanya terkait pada individu tetapi diterima oleh sebuah group/domain”.

    • Barnaras, “Sebuah ontologi memberikan pengertian untuk penjelasan secara eksplisit dari konsep terhadap representasi pengetahuan pada sebuah knowledge base”.

    • Knight, “Sebuah ontologi adalah sebuah struktur hirarki dari istilah untuk menjelaskan sebuah domain yang dapat digunakan sebagai landasan untuk sebuah knowledge base”.

    • Jeff Heflin, “Ontologi mendefinisikan sebuah istilah yang digunakan untuk menjelaskan dan merepresentasikan daerah pengetahuan. Ontologi digunakan bagi orang-orang, database, dan aplikasi yang perlu berbagi informasi domain (domain hanya daerah subyek tertentu atau bidang pengetahuan, seperti obat-obatan, alat manufaktur, real estate, perbaikan mobil, manajemen keuangan, dll). Ontologi termasuk definisi komputer yang digunakan dalam konsep dasar domain dan hubungan di antaranya”

    Pada tinjauan filsafat, ontologi adalah studi tentang sesuatu yang nyata. Ontologi adalah suatu teori yang dapat menjelaskan tentang makna suatu objek, property dari suatu objek dan relasi objek tersebut yang mungkin terjadi pada suatu domain pengetahuan.

    Dalam bidang Artificial Intelligence (AI), ontologi memiliki dua pengertian yang saling berkaitan:

    1. Merupakan representasi kosakata yang sering dikhususkan untuk domain atau subjek pembahasan tertentu.

    2. Sebagai suatu body of knowledge untuk menjelaskan suatu bahasan tertentu. Bersama dengan beberapa set instances dari class membentuk sebuah knowledge base.

    b. Komponen Ontologi

    Ontologi memilki beberapa komponen yang dapat menjelaskan ontologi tersebut, diantaranya [8]:

    • Konsep (Concept)

    Digunakan dalam pemahaman yang luas. Sebuah konsep dapat sesuatu yang dikatakan, sehingga dapat pula merupakan penjelasan dari tugas, fungsi, aksi, strategi, dan sebagainya. Concept juga dikenal sebagai classes, object dan categories.

    • Relasi (relation)

    Merupakan representasi sebuah tipe dari interaksi antara konsep dari sebuah domain. Secara formal dapat didefinisikan sebagai subset dari sebuah produk dari n set, R:C1 x C2 x…xCn. Sebagai contoh dari relasi binary termasuk subclass-of dan connected-to.

    • Fungsi (functions)

    Adalah sebuah relasi khusus dimana elemen ke-n dari relasi adalah unik untuk elemen ke n-1. F:C1 x C2 x …Cn-1 – > Cn, contohnya adalah Mother-of.

    • Aksioma (axioms)

    Digunakan untuk memodelkan sebuah sentence yang selalu benar.

    • Instances

    Digunakan untuk merepresentasikan elemen.

    Untuk dapat digunakan, sebuah ontologi harus diekspresikan dalam notasi yang nyata. Sebuah bahasa ontologi adalah sebuah bahasa formal dari sebuah pengembangan ontologi. Beberapa komponen yang menjadi struktur ontologi, antara

    lain [5]:

    • XML (Extensible Markup Langguage)

    Menyediakan sintaksis untuk output dokumen terstruktur, tetapi belum dipaksakan untuk dokumen XML menggunakan semantic constrains.

    • XML Schema

    Bahasa untuk pembatasan struktur dari dokumen XML.

    • RDF (Resource Description Framework)

    Model data untuk obyek (‘resources’) dan relasi diantaranya, menyediakan semantic yang sederhana untuk model data tersebut, dan data model ini dapat disajikan dalam sintaksis XML.

    • RDF Schema

    Adalah kosakata untuk menjelaskan properties dan classes dari sumber RDF, dengan sebuah semantics untuk hirarki penyamarataan dari properties dan classes.

    • OWL (Ontologi Web Langguage)

    Menambahkan beberapa kosakata untuk menjelaskan properties dan classes, antara lain : relasi antara classes (misalkan disjointness), kardinalitas (misalkan ‘tepat satu’), equality, berbagai tipe dari properties, karakteristik dari properties (misalkan symmetry), menyebutkan satu persatu classes.

    Struktur lapisan ontologi ditunjukkan seperti gambar 1. Setiap lapis akan memiliki fungsi tambahan dan kompleksitas tambahan dari lapis sebelumnya. Pengguna atau user yang memiliki fungsi pemrosesan lapisan paling rendah dapat memahami walaupun tidak seluruh ontologi yang terletak di lapis atasnya.

    gmb1_ontologi

    Gambar 1. Struktur Lapisan Ontologi [5]

    2. Konsep dasar Web 3.0

    Domain Pengetahuan

    Domain pengetahuan seperti Fisika, Kimia, Biologi, Politik, Web, Sosiologi, Psikologi, Sejarah, dll, terdapat banyak sub-domain di bawah setiap domain, masing-masing memiliki sub-domain dan sebagainya.


    Informasi versus Pengetahuan

    Untuk suatu mesin, pengetahuan adalah memahami informasi (informasi baru yang dihasilkan melalui penerapan deduktif reasoning untuk meninggalkan informasi). Untuk suatu mesin, informasi hanyalah data, sehingga informasi adalah mengenai alasan.


    Mesin Inferensi

    Dalam konteks Web 3.0, mesin inferensi akan menggabungkan inovasi terbaru dari bidang kecerdasan buatan (AI) bersama-sama dengan domain khusus ontologi, domain inference rules, dan struktur query untuk mengaktifkan deduktif reasoning pada tingkat mesin.

    Info Agens

    Info Agens adalah contoh dari suatu Inference Engine, masing-masing bekerja sama dengan domain khusus ontologi. Dua atau lebih agen yang bekerja bersama-sama dengan ontologi mungkin berkolaborasi untuk menarik kesimpulan jawaban atas pertanyaan. Seperti kerjasama agens mungkin didasarkan pada perbedaan rancangan Inference Engine dan mereka masih dapat bekerja sama.

    Bukti dan Jawaban

    Hal yang menarik tentang Info Agens adalah bahwa mereka akan mampu tidak hanya menarik kesimpulan jawaban dari informasi yang ada (yakni menghasilkan informasi baru [dan mendapatkan pengetahuan dalam proses, bagi agen dengan fungsi pembelajaran] ) namun mereka juga akan dapat secara formal menguji proposisi (diwakili dalam beberapa query logika) yang dilakukan secara langsung-atau-diterapkan oleh pengguna.

    Semantik Web

    Semantik web adalah sebuah web dengan arti. Arti disini memungkinkan komputer memahami arti dari sebuah informasi berdasar pada Metadata yaitu data mengenai data. Metadata ini mengandung informasi mengenai isi dari suatu data yang dipakai untuk keperluan manajemen file/data itu nantinya dalam suatu basis data. Dengan adanya Metadata, komputer diharapkan mampu secara otomatis membantu manusia mengartikan hasil proses informasi sehingga hasil pencarian informasi menjadi lebih akurat.

    Internet membutuhkan suatu mekanisme yang memampukan komputer mengerti arti kata yang kita cari. Dengan kata lain, kita membutuhkan suatu cara agar kata-kata yang tertera di dalam suatu dokumen Web dapat dibaca dan dimengerti oleh mesin (machine-readable data). Website yang memiliki kemampuan seperti ini seolah-olah memiliki kecerdasan buatan yang sanggup memberikan jawaban yang tepat terhadap pertanyaan atau kebutuhan para penggunanya. Para peniliti setuju bahwa Semantic Web merupakan suatu cara untuk melakukan revolusi di dunia Internet yang akan menyatukan interaktifitas pengguna, kolaborasi informasi, dan kecerdasan buatan pada sebuah Website. [6]

    Perkembangan web

    Web 1.0

    Web 1.0 merupakan teknologi Web generasi pertama yang merupakan revolusi baru di dunia Internet karena telah mengubah cara kerja dunia industri dan media. Pada dasarnya, Website yang dibangun pada generasi pertama ini secara umum dikembangkan untuk pengaksesan informasi dan memiliki sifat yang sedikit interaktif. Berbagai Website seperti situs berita “cnn.com” atau situs belanja “Bhinneka.com” dapat dikategorikan ke dalam jenis ini.

    Web 2.0

    Istilah Web 2.0 pertama kalinya diperkenalkan oleh O’Reilly Media pada tahun 2004 sebagai teknologi Web generasi kedua yang mengedepankan kolaborasi dan sharing informasi secara online. Menurut Tim O’Reilly, Web 2.0 dapat didefinisikan sebagai berikut:

    “Web 2.0 adalah revolusi bisnis di industri komputer yang disebabkan oleh penggunaan internet sebagai platform, dan merupakan suatu percobaan untuk memahami berbagai aturan untuk mencapai keberhasilan pada platform baru tersebut. Salah satu aturan terutama adalah: Membangun aplikasi yang mengeksploitasi efek jaringan untuk mendapatkan lebih banyak lagi pengguna aplikasi tersebut”

    Berbagai layanan berbasis web seperti jejaring sosial, wiki dan folksonomies (misalnya: “flickr.com”, “del.icio.us”) merupakan teknologi Web 2.0 yang menambah interaktifitas di antara para pengguna Web. Pada umumnya, Website yang dibangun dengan menggunakan teknologi Web 2.0 memiliki fitur-fitur sebagai berikut:

    • CSS (Cascading Style Sheets)

    • Aplikasi Rich Internet atau berbasis Ajax

    • Markup XHTML

    • Sindikasi dan agregasi data menggunakan RSS/Atom

    • URL yang valid

    • Folksonomies

    • Aplikasi wiki pada sebagian atau seluruh Website

    • XML Web-Service API

    Web 3.0 / Semantic Web

    Walaupun masih dalam perdebatan di kalangan analis dan peneliti, istilah Web 3.0 tetap berpotensi menjadi generasi teknologi di dunia Internet. Saat ini, definisi untuk Web 3.0 sangat beragam mulai dari pengaksesan broadband secara mobile sampai kepada layanan Web berisikan perangkat lunak bersifat on-demand. Pada dasarnya Semantic Web memiliki tujuan yang sama karena Semantic Web memiliki isi Web yang tidak dapat hanya diekpresikan di dalam bahasa alami yang dimengerti manusia, tetapi juga di dalam bentuk yang dapat dimengerti, diinterpretasi dan digunakan oleh perangkat lunak (software agents). Melalui Semantic Web inilah, berbagai perangkat lunak akan mampu mencari, membagi, dan mengintegrasikan informasi dengan cara yang lebih mudah. Pembuatan Semantic Web dimungkinkan dengan adanya sekumpulan standar yang dikoordinasi oleh World Wide Web Consortium (W3C). Standar yang paling penting dalam membangun Semantic Web adalah XML (atau Link ini tentang XML di website W3 : XML), XML Schema, RDF, OWL, dan SPARQL [7].

    Kesimpulan

    • Ontologi merupakan cabang ilmu filsafat mengenai obyek nyata, namun memiliki kemampuan yang sistematis untuk dapat menjelaskan mengenai suatu objek, atribut objek dan hubungan antar objek.

    • Ontologi banyak diadopsi kedalam aplikasi Artificial Intelligence (AI) dalam representasi pengetahuan.

    • Kolaborasi Ontologi dan AI kedalam Semantic Web menawarkan sebuah solusi bagi pemrosesan informasi di Web.

    • Penelitian dan pengembangan tools untuk Semantic Web masih harus terus dilakukan agar di kemudian hari berbagai aplikasi Semantic Web dapat diimplementasikan dan dipergunakan secara luas.

    DAFTAR PUSTAKA

    1. W3C. http://http://www.w3.org/tr/2002/wd-rdf-schema-20020430/, 5 2009.

    2. W3C. http://www.w3.org/TR/2004/REC-webont-req-20040210/, 5 2009.

    3. I Wayan Simri Wicaksana. “Survei dan Evaluasi Metode Pengembangan Ontologi”, http://paperwgdbis.abmutiara.info/2004-01_Kommit2004_Survei_IWS.pdf, 5.2009
    4. I Wayan Simri Wicaksana. “Pengujian Tool Ontologi Engineering”. http://amutiara.files.wordpress.com/2007/01/2006_07_kommit06_membandingkantoolontodev_iws.pdf, 5.2009
    5. _____,ONTOLOGI : Bahasa dan Tools PROTÉGÉ, http://paperwgdbis.abmutiara.info/tutorial/Bahasa_tool_ontology.pdf, 5.2009
    6. _____, Web 3.0: Basic Concepts, http://evolvingtrends.wordpress.com/2006/06/30/why-p2p-ai-will-kill-google/, 5.2009
    7. Niko Ibrahim, “Pengembangan Aplikasi Semantic Web Untuk Membangun Web yang Lebih Cerdas”, http://www.itmaranatha.org/jurnal/jurnal.informatika/Jurnal/Juni2007/artikel/artikelpdf/juni07_3.pdf, 5.2009
    8. Coral Calero dan kawan,“ Ontologies for Software Engineering and Software Technology”, Springer-Verlag Berlin Heidelberg, New York, 2006.




    Lebih lanjut tentang OOP dengan bahasa pemrograman JAVA

    2 08 2009

    Oleh : Teguh Sutopo

    Bahasa pemrograman JAVA merupakan bahasa pemrograman modern yang saat ini banyak digunakan dalam berbagai aplikasi. Bahasa pemrograman JAVA menerapkan paradigma full OOP. Bagi programmer pemula, untuk mengenal OOP akan jauh lebih mudah dengan menggunakan bahasa pemrograman JAVA.

    Kelas (Class) Kekuatan OOP pada JAVA

    Kelas (Class) merupakan kekuatan OOP. Kelas adalah sebuah kumpulan dari variabel-variabel yang disebut dengan atribut dan fungsi-fungsi yang disebut dengan metode (method), dimana elemen-elemen tersebut saling berinteraksi. Kelas menjelma menjadi type baru. Dari kelas inilah obyek (object) diciptakan. Kelas memberikan bentuk dan prilaku dari sebuah obyek.

    Berikut contoh untuk memahami tentang kelas (class) dan obyek (object)

    ooplanjut01

    Kelas sederhana

    ooplanjut02 Hasil eksekusi yang tampak di konsol

    Dari contoh kelas (class) sederhana tersebut dapat dijelaskan sebagai berikut :

    1. public class AsslClass pada baris pertama merupakan deklarasi nama kelas yaitu AssClass. Kelas tersebut bersifat publik ditandai dengan kata kunci public yang artinya dapat diakses dari luar maupun dalam kelas. Kata kunci class merupakan deklarasi dari kelas. Perlu diingat bahwa nama file saat menyimpan kelas tersebut harus sama dengan nama kelas yaitu AsslClass dan dengan ektensi java, jadi nama file yang terbentuk yaitu AsslClass.java. JAVA bersifat case sensitive yaitu membedakan huruf besar kecil. Nama kelas harus dimulai dengan huruf dan setelah itu dapat dikombinasi dengan bilangan.

    2. Seperti dalam bahasa pemrograman C/C++, dalam satu program eksekusi hanya terdapat satu fungsi main() sebagai program utama yang akan dieksekusi. Pada JAVA, kelas yang akan dieksekusi harus mengandung metode (method) main(), JAVA memulai mengeksekusi dari metode tersebut yaitu public static void main(String [] args).

    3. System.out.println(“Assalamu’alaikum”) adalah metode untuk menampilkan string parameter Assalamu’alaikum di layar konsol. Metode println terdapat pada obyek out dan berada pada kelas System.

    4. Setiap baris pernyataan harus diakhiri dengan tanda titik koma ; (semicolon), sedangkan pasangan kurung kurawal merupakan tanda awal dan akhir dari blok / badan metode.

    Contoh lain. Dari program contoh di atas kita kembangkan dengan menambah satu metode (method) yaitu cetakAssl() yang berfungsi menampilkan string Assalamu’alaikum di konsol, di mana motode System.out.println(“Assalamu’alaikum”) tidak kita tempatkan di metode main() tapi kita tempatkan di metode cetakAssl(). Pada metode main() kita ganti dengan penyataan memanggil metode cetakAssl().

    ooplanjut03

    Kelas dengan sebuah metode selain main()

    ooplanjut04 Hasil eksekusi yang tampak di konsol

    Tentu saja kita dapat menambahkan berbagai metode dengan fungsi-fungsi yang berbeda sesuai tujuannya serta atribut-atribut (variabel-variabel, konstanta, dll) dalam kelas tersebut. Berikut contoh lain kelas dengan atribut dan metode serta penciptaan obyek

    1. Kelas KotakClass berisi satu method main(), menghitung luas permukaan balok dan isi dengan atribut lebar, panjang, tinggi, luas dan isi.

    ooplanjut05ooplanjut06

    2. Kelas KotakClass dikembangkan dengan menambah satu method hitungLuasIsi() dengan parameter lebar, panjang dan tinggi dimana parameter-parameter tersebut bertipe double. Semua baris pernyataan di method main() di pindah ke method hitungLuasIsi dan atribut luas dan isi dikeluarkan dari kelas main() menjadi variabel global. Tentunya adanya variabel global tidak dikehendaki dalam konsep OOP. Method main() hanya berisi pernyataan pemanggilan method hitungLuasIsi yang disertai dengan tiga nilai parameter.

    ooplanjut07

    3. pengembangan berikutnya kita pisahkan method hitungLuasIsi() dan atribut luas dan isi ke dalam bentuk kelas (class) tersendiri. Kelas tersebut menjadi tipe baru yang akan kita gunakan untuk membuat obyek, sehingga kelas induk yaitu kelas KotakAksi hanya berisi method main() dan berfungsi membentuk obyek serta mengeksekusinya.

    ooplanjut09ooplanjut08

    4. Kelas baru yang kita bentuk adalah kelas Kotak dan disimpan dalam file tersendiri yaitu Kotak.java. Kelas inilah yang akan kita gunakan untuk membentuk obyek.

    ooplanjut09

    5. Kelas KotakAksi kita jadikan kelas utama dimana pada kelas tersebut terdapat method main() yang akan membuat obyek dari kelas Kotak.

    ooplanjut10

    ooplanjut11





    Pemrograman berorientasi obyek / Object Oriented Programming (OOP)

    2 08 2009

    Oleh : Teguh Sutopo

    Pemrograman prosedural

    Ketika pertama saya belajar program pada tahun 1984, bahasa pemrograman BASIC adalah yang pertama saya kenal. Setiap baris perintah menggunakan nomor urut (bilangan bulat/integer) dari yang kecil ke yang besar (Ascending). Yang repot kalau mau menyisipkan baris perintah, sementara tidak ada nomor cadangan alias nomor di antara dua baris yang akan disisipi. Biasanya menggunakan teknik penomoran kelipatan 10 agar ada tempat untuk menyisipkan baris perintah. Program bekerja atau dieksekusi mulai nomor terkecil, untuk jump (“Goto”) menunjuk nomor baris atau label. Yang bikin repot dan pusing jika program cukup panjang (ratusan baris perintah) dan ada kesalahan yang harus dilacak, persis mencari kutu (debug). Pemrograman dengan metodologi tersebut dinamakan step by step.

    oop1

    Contoh program dengan bahasa BASIC

    Ketika kerja di konsultan Tyssen GmbH untuk proyek Production Control System (PCS) pabrik Hot Strip Mill, PT.Krkatau Steel pada tahun 1987, program komputer dibuat dengan menggunakan bahasa pemrograman dBase II untuk Personal Computer (PC) dan FORTRAN dan RPG untuk komputer mini IBM AS400. Pada bahasa pemrograman ini saya kenal dengan namanya procedure dan function, program dipecah-pecah menjadi beberapa modul. Metodologi pemrograman tersebut diistilahkan dengan modular atau prosedural. Dibanding dengan metodologi step by step, metodologi prosedural cukup baik, karena program dipecah menjadi modul-modul prosedur dan fungsi yang relatif mudah dimanage. Pada metodologi tersebut kerepotan ditemui saat program mulai komplek, perubahan suatu fungsi akan berpengaruh pada fugsi sistem secara keseluruhan dan saat diintegrasikan dengan sistem lain.

    oop2

    Contoh program dengan dBASE

    Kedua metodologi tersebut step by step dan prosedural pada prinsipnya sama yaitu flow programming yang dieksekusi mulai baris awal perintah sampai baris akhir. Pada metodologi tersebut antara data (variabel, konstanta, dll) dan metode (prosedur dan fungsi) dipandang sendiri-sendiri secara terpisah.

    Pemrograman berorientasi obyek.

    Pada tahun 1989, saya keluar dari konsultan Tyssen GmbH dan menjadi konsultan freelance bersama rekan saya dari Amerika eks konsultan Caesar dan mengerjakan proyek PCS di PT.CRMIU (sekarang sahamnya dibeli PT. KS dan menjadi Divisi PBLD) . Pada proyek tersebut kami menggunakan bahasa pemrograman Turbo Pascal 5.5 dan kemudian diupgrade ke Turbo Pascal 7. Pada bahasa pemrograman ini saya kenal dengan yang namanya pemrograman berorientasi obyek atau Object Oriented Programming (OOP).

    oop3

    Contoh program berorientasi obyek yang ditulis dengan PASCAL 7

    OOP merupakan perkembangan / pembaharuan dari paradigma pemrograman prosedural. OOP dibuat untuk mengatasi kesulitan yang ada pada pemrograman prosedural yang komplek. OOP merupakan paradigma yang berbeda dengan pemrograman prosedural. Obyek (object) dimaksud dalam pemrograman yaitu kumpulan elemen-elemen dalam suatu program dan hubungan yang terjadi antar elemen tersebut.

    Bila pada pemrograman prosedural, data (variabel, konstanta, dll), metode (prosedur dan fungsi) dan hubungan satu dengan lainnya dapat terpisah, maka pada OOP elemen-elemen serta hubungannya dikemas dalam suatu modul yang dinamakan kelas (class). Kelas inilah yang digunakan untuk membangun atau membentuk obyek. Meminjam istilah mas Romi Satria Wahono, bahwa kelas ibarat cetakan kue, dan obyek adalah kue yang dihasilkan (instance) dari cetakan dimaksud.

    Terdapat 3 pilar utama dalam pemrograman yang berorientasi obyek, ketiga pilar tersebut yaitu:

    1. Encapsulation (pengkapsulan), merupakan langkah pengkombinasian data dan berbagai metode yang berhubungan dengannya. Hasil dari kombinasi yang dlakukan inilah yang disebut obyek (Object) yang merupakan tipe data baru.

    2. inheritance (penurunan sifat / pewarisan), ini merupakan ciri khas dari OOP yang tidak terdapat pada pemrograman prosedural gaya lama. Dalam hal ini, inheritance bertujuan membentuk obyek baru yang memiliki sifat sama atau mirip dengan obyek yang sudah ada sebelumnya (pewarisan). Obyek turunan dapat digunakan membetuk obyek turunan lagi dan seterusnya. Setiap perubahan pada obyek induk, juga akan mengubah obyek turunannya. Susunan obyek induk dengan obyek turunannya disebut dengan hirarki obyek.

    3. Polymorphism, suatu aksi yang memungkinkan pemrogram menyampaikan pesan tertentu keluar dari hirarki obyeknya, dimana obyek yang berbeda memberikan tanggapan/respon terhadap pesan yang sama sesuai dengan sifat masing-masing obyek.

    Dari uraian di atas, dapat dianalogikan perbedaan antara pemrograman prosedural dan OOP, yaitu seperti seorang programmer memandang sebuah kaleng. Menurut cara pandang aliran prosedural gaya lama, maka ia akan mendeklarasikan beberapa variabel untuk menggambarkan kaleng tersebut. Misal variabel R untuk jari-jari, Tng untuk tinggi, Phi untuk konstanta phi, Wrn untuk warna, Ls untuk luas permukaan, dan seterusnya. Jadi untuk masing-masing bagian kaleng tersebut direpresentasikan ke dalam variabel-variabel terpisah. Begitu juga untuk fungsi dan atau prosedur. Bagi programmer aliran OOP, data-data dimaksud yang disebut dengan atribut dan fungsi atau prosedur yang disebut metode (method) dikemas dalam satu tipe baru yang disebut dengan kelas (class). Dari class inilah nantinya diciptakan obyek-obyek.