Prinsip Pemodelan

Rekayasa perangkat lunak merupakan salah satu keilmuan dengan perkembangan yang pesat. Menurut McConnel [McC99], software engineering body of knowledge telah menemukan “kestabilan utama” yang merepresentasikan sekitar 75% pengetahuan yang diperlukan untuk mengembangkan perangkat lunak yang kompleks. Jadi, dapat disimpulkan, bahwa hanya dalam kurun waktu 50 tahun, maka rekayasa perangkat lunak makin mapan.
Salah satu “titik puncak” dalam rekayasa perangkat lunak, adalah pemodelan perangkat lunak. Pemodelan memberikan kemampuan baru kepada pengembang perangkat lunak dengan pendekatan sistematik dan terorganisasi dalam mengembangkan perangkat lunak, berdasarkan prinsip rekayasa. Pemodelan juga menegaskan proses pengambilan-keputusan terkait segenap aspek dalam pengembangan perangkat lunak. Selain itu, pemodelan memperkuat proses komunikasi antar pihak2 yang terkait dalam pemanfaatan perangkat lunak.

Terdapat beberapa prinsip umum yang memandu aktivitas pemodelan perangkat lunak:
1) Fokus pada esensi utama – dalam pemahaman bahwa model perangkat lunak “hanyalah” mengilustrasikan bagian-bagian terpenting (dan kritis) dalam arsitektur perangkat lunak yang dikembangkan. Dalam konteks ini, prinsip “penyederhanaan” adalah isu yang terpenting dalam membuat model essentials dari perangkat lunak. Membuat model, secara kasar dapat dikatakan sebagai membuat penyederhanaan.
2) Menyediakan perspektif – Pemodelan perangkat lunak harus dapat memberikan wawasan yang menyeluruh dari segenap aspek pengembangan perangkat lunak. Wawasan atau perspektif menyeluruh ini, tentu saja, harus sesuai dengan standar aturan tertentu yang diterima komunitas pengembang dan dapat dipahami pengguna perangkat lunak. Pendekatan perspektif ini harus dapat menggambarkan dimensi perangkat lunak.
3) Memungkinkan komunikasi efektif – Model perangkat lunak berisi kosakata, bahasa dan ekspresi semantik dari perangkat lunak. Kesemuanya ini dimaksudkan untuk memperlancar proses komunikasi intern (dalam tim pengembang) dan ekstern (antar tim pengembang dan stakeholders).
Secara teknis dapat dikatakan bahwa model perangkat lunak merupakan abstraksi (atau penyederhanaan) dari setiap komponen yang membangun suatu perangkat lunak. Abstraksi yang ada bukanlah abstraksi tunggal, melainkan merupakan gabungan (atau kumpulan) beberapa abstraksi terkait komponen-komponen perangkat lunak. Sehingga, melalui kumpulan abstraksi ini, pihak-pihak yang terkait mendapatkan wawasan yang lengkap dan dapat memahami perangkat lunak yang akan dibangun. Model yang baik, tentu saja, dapat digunakan berulang-ulang dengan asumsi yang dapat divalidasi terkait hasil akhir yang dikembangkan.

Karakteristik dari model perangkat lunak:
1) Completeness – yakni terkait dengan seberapa lengkap requirements perangkat lunak yang telah digambarkan (dan diverifikasi) pada sebuah model
2) Consistency – yakni terkait dengan keselarasan antar setiap komponen perangkat lunak yang dikembangkan dengan model yang diabstraksi. Konsistensi misalnya dapat dinyatakan dengan tidak adanya konflik pada deskripsi requirements, ataupun pada deskripsi fungsi dari perangkat lunak yang dibangun.
3) Correctness – aspek ini terkait dengan keterunutan (keterlacakan) antara requirements, spesifikasi perancangan hingga pengujian yang menjamin bebas cacat. Model yang baik harus dapat mengekspresikan keterunutan setiap proses pengembangan perangkat lunak.

(gambar diambil dari http://www.sitechno.com/blog/content/binary/EF_TBT_ConceptualModel.jpg)

Biar bagaimanapun juga, sebuah model yang baik, harus dapat menggambarkan “kondisi nyata” dari karakteristik dan perilaku obyek tertentu, sehingga dapat menjelaskan bagaimana nantinya sebuah perangkat lunak itu menjalankan fungsinya. Sehingga dengan demikian, dapat dikatakan bahwa ekspresi elemen utama sebuah model itu adalah entitas. Entitas mewakili artifak yang konkret (seperti misalnya sensor atau prosesor) dan artifak yang abstrak (seperti misalnya modul perangkat lunak dan protokol komunikasi data). Tentu saja, model yang baik, juga dapat menunjukkan relasi antar entitas tersebut. Ekspresi entitas dan relasi entitas ini digambarkan dengan “bahasa” teks dan grafis.

Sintaks, Semantik dan Pragmatisme
Bagi pengembang senior, maka dia pasti sudah menemukan bahwa seringkali model perangkat lunak bisa menipu. Karena memang, model sebagai hasil abstraksi memilki kecenderungan untuk menampilkan informasi yang tidak lengkap (atau tidak utuh). Oleh karena itu, penting untuk menyadari bahwa model yang lengkap (atau utuh) itu adalah gabungan dari beberapa sub-model dan model fungsi khusus dari perangkat lunak yang akan dibangun. Pengalaman menunjukkan bahwa pemeriksaan dan pengambilan keputusan yang hanya didasarkan pada model tunggal, akan membawa masalah baru dalam proses pengembangan perangkat lunak.

Penting bagi seorang pengembang untuk memahami dengan tepat arti dari konstruksi sebuah model perangkat lunak. Usaha ini merupakan pekerjaan yang cukup berat. Bahasa pemodelan biasanya didefinisikan dengan aturan-aturan sintak dan semantik tertentu. Untuk bahasa model tekstual, digunakan konstruksi bahasa formal yang valid (misalnya BNF atau Backus-Naur Form). Untuk bahasa model grafis, sintaks didefinisikan dengan model grafik yang disebut meta-models. Semantik bahasa pemodelan menyatakan arti yang melekat pada entitas dan relasi yang diungkapkan pada gambar model perangkat lunak. Seperti misalnya sebuah diagram sederhana dari dua buah kotak yang terhubung dengan garis lurus, akan terbuka untuk berbagai interpretasi artian. Pengembang harus mengetahui konteks diagram tersebut, seperti misalnya dalam Diagram Object dan Diagram Aktivitas yang dapat membantu penafsiran arti gambar model tersebut.
Secara praktis, maka pengembang harus dapat beradaptasi dengan abstraksi model yang secara mendasar hanya menampilkan informasi yang tidak utuh. Komunikasi yang tepat pada intinya adalah pihak-pihak yang berkomunikasi dapat  menangkap makna/arti yang sama dari notasi pada gambar model yang digunakan. Pemahaman akan sintaks yang digunakan, semantik yang digambarkan dan konteks gambar model sangat penting untuk para pengembang dan stakeholders terkait pengembangan perangkat lunak.

Types of Models
Sebuah model, pada dasarnya merupakan agregasi dari beberapa sub-model. Setiap sub-model merupakan deskripsi parsial yang dikhususkan untuk tujuan khusus tertentu; dan dinyatakan oleh satu atau beberapa diagram. Kumpulan sub-model dapat terdiri dari beberapa bahasa pemodelan, atau bahasa pemodelan tunggal seperti misalnya UML.
Sekarang ini, model dibedakan menjadi model informasi, model perilaku dan model struktur.

Model informasi menyatakan data dan informasi yang ada pada perangkat lunak. Model ini merupakan representasi abstrak dari konsep, properties, relasi dan constraint dari entitas data. Model informasi sering digunakan untuk menyatakan konteks formal dari perangkat lunak yang dilihat dari sudut pandang permasalahan yang akan diselesaikan tanpa memikirkan bagaimana model ini diimplementasikan pada perangkat lunak.
Model Perilaku menyatakan fungsi dari perangkat lunak yang akan dikembangkan. Model perilaku biasanya dinyatakan dalam bentuk: state machines, model aliran-kontrol dan model aliran data. State Machines menyatakan perangkat lunak yang terdiri dari kumpulan states (keadaan yang terdefinisi), events dan transisi. Model aliran kontrol menyatakan sebuah sequence of events yang menyebabkan proses dieksekusi atau dihentikan. Model aliran data biasanya menggambarkan perilaku data yang bergerak melalui masuk atau keluar proses penyimpanan data.
Model Struktur mengilustrasikan komposisi logis (atau fisik) dari berbagai komponen dari perangkat lunak. Pemodelan struktural menjelaskan batasan dari perangkat lunak yang diimplementasikan dan lingkungan tempat dimana perangkat lunak akan difungsikan/dijalankan.

The Value of Modeling

Pemodelan software merupakan salah satu perkembangan terkini dalam pengembangan perangkat lunak. Terlepas dari banyaknya kesalahpahaman mengenai apa yang dimaksud dengan "pemodelan" perangkat lunak tersebut, teknik-teknik dalam melakukan pemodelan perangkat lunak, makin berkembang luas.

Salah satu "kebiasaan" para programmer pemula adalah seperti yang disebutkan pada kalimat ini: "rush to code syndrome" atau sindrom yang (selalu) ingin cepat menulis kode program. Kebiasaan ini, terlihat pada hampir semua programmer entry-level (maupun programmer template). Biasanya mereka, tanpa pikir panjang, langsung menulis kode (ataupun menggunakan template) dengan alasan ingin cepat2 mendelivered sebuah aplikasi bagi user.

Dalam software engineering, pendekatan "rush to code syndrome" menyebabkan Software Crisis 1.0 di Era 1960-an s/d 1970-an. Era Software Crisis tersebut, menghasilkan aplikasi perangkat lunak yang amburadul dari sisi biaya pengembangan yang membengkak, terlambat mendelivered perangkat lunak karena tidak adanya kontrol fitur-fitur yang dikembangkan dan buruknya manajemen pengelolaan proses perangkat lunak. Akibat yang paling nyata adalah dihasilkannya "sampah software" yang sungguh tak terhitung jumlahnya. (Sampah software adalah software yang ditinggalkan, karena tidak bermanfaat).

Pemodelan perangkat lunak relatif menghindarkan organisasi untuk mengalami kondisi "software crisis". Secara kasar, dapat dikatakan, proses pemodelan perangkat lunak, merupakan bagian dari pendekatan membuat perangkat lunak dengan berprinsip pada software system engineering, atau berpedoman pada prinsip rekayasa teknik yang reliable dan precise.

Disamping makin kompleksnya dunia pengembangan perangkat lunak, dewasa ini, maka langkah pemodelan software menjadi makin penting. Sedikitnya IBM Rational SOftware Team mengusulkan beberapa Tren terkait Pemodelan Perangkat Lunak. Tren tersebut adalah:

1) Beyond visual modeling; yakni pemodelan model, atau pemodelan dari model visual.

2) Unifying software, data and business modeling atau pemodelan yang menyeluruh, dalam artian model interasi dari aliran data, informasi, logic business dan aplikasi itu sendiri.

3) Modeling across lifecycle; atau pemodelan yang berkesinambungan mencakup seluruh langkah-proses daur hidup pengembangan perangkat lunak.

4) Domain-specific modeling language, atau bahasa pemodelan dengan sintaks dan semantics yang dapat diterima secara internasional

5) Model-driven architecture; atau suatu "next-step" mengenai pemodelan tingkat lanjut.

Selengkapnya dari tulisan tersebut diatas, dapat diunduh pada tautan dibawah ini:

http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/ValueOfModeling.pdf

Kalkulus, Oh Kalkulus ...

Perkuliahan semester ganjil TA 2012/2013 di Prodi Teknik Informatika, Fakultas Teknik, Universitas Sam Ratulangi, dimulai dengan sedikit berbeda. Disamping banyaknya peminat dan mahasiswa baru yang masuk (sekitar 160-an maba), saya juga dipercayakan untuk mengampu mata kuliah Kalkulus.

Sebenarnya, Kalkulus dalam dunia Informatika ada dua; 1) Kalkulus Klasik (atau Newtonian) dan 2) Kalkulus Ilmu Komputer. Kalkulus Klasik berhubungan dengan "preciseness" atau ketepatan, sedangkan Kalkulus Ilmu Komputer (diberi nama mata kuliah: Logika Informatika) berhubungan dengan "validity" atau pembuktian kebenaran.

(Gambar diambil dari http://www.vias.org/calculus/img/12_multiple_integrals-77.gif)

Cakupan pembahasan materi Kalkulus Klasik, dimulai dengan Teori Bilangan, hingga konsep dan penerapan Limit, Turunan dan Integral. Kesemuanya diarahkan untuk memberikan dasar "kompetensi" untuk mata kuliah Metode Numerik (atau Komputasi Numerik). Inti pembahasannya adalah PRECISENESS, atau dengan kata lain, bagaimana mengelola ERROR.

Cakupan pembahasan materi Kalkulus Ilmu Komputer, berkisar pada Logika Proporsional, Logika Predikat dan "berbagai" metode pembuktian kebenaran yang ada. Seperti ditulis sebelumnya, aspek VALIDITY merupakan fokus bahasan mata kuliah ini.

Kedua mata kuliah ini, merupakan dasar bagi setiap mereka yang ingin menekuni keilmuan informatika, rekayasa perangkat lunak dan teknologi informasi. Kepentingan pemahaman teori kedua "jenis" Kalkulus ini merupakan suatu mandatory bagi para mahasiswa yang menekuni keilmuan Informatika ini.

Kalkulus Proposisi

(gambar diambil dari http://ririsatria40.files.wordpress.com/2011/02/moivre.jpg)

Sering terdengar pernyataan bahwa matematika diajarkan untuk mendidik murid berpikir secara praktis, teratur, murni, tajam dan logis. Apakah sebenarnya berpikir secara logis itu ?

Suatu ucapan benar atau salah disebut sebagai suatu pernyataan atau kalimat. Setiap pernyataan adalah suatu ucapan, tetapi tidak setiap ucapan merupakan suatu pernyataan. 

Contoh,

a. Marilah ke sini.

b. Siapakah namamu.

c. Betapa indahnya.

Semuanya adalah ucapan – ucapan, tetapi bukan merupakan suatu pernyataan, karena ucapan – ucapan tersebut tidak dapat dinyatakan sebagai benar atau salah. 

Kalimat yang menerangkan sesuatu atau menyatakan sesuatu yang dapat dianggap sebagai pernyataan, misalnya,

1. Paris adalah ibukota Perancis.

2. Dua adalah suatu bilangan asli.

Pernyataan (1) dan (2) di atas dinyatakan sebagai benar, karena menerangkan atau menyatakan sesuatu hal yang benar.

Dalam logika, kata – kata seperti “dan”, “atau”, “tidak”, “jika … maka”, dan lain – lain memegang peranan yang sangat penting. Kata – kata tersebut merangkaikan buah pikiran, relasi – relasi dan cara yang dilakukan, yang disebut sebagai struktur logis dari suatu pernyataan. 

Contoh, 

Pernyataan – pernyataan berikut memiliki struktur logis yang sama,

a. Setiap orang adalah laki – laki atau perempuan.

b. Setiap zat adalah organis atau anorganis.

c. Setiap penduduk adalah warga negara atau warga asing.

Pernyataan di atas bisa digambarkan dengan skema sebagai berikut,

“Setiap … (i) … adalah … (ii) … atau … (iii) …”,

dengan (i), (ii) dan (iii) merupakan kata benda atau kata nama.

Kebenaran dari pernyataan di atas tergantung dari struktur logisnya dan tidak tergantung pada isi pernyataan. Pernyataan yang demikian dikatakan benar secara logis atau selalu benar. Contoh lain,

“Jika setiap manusia adalah fana dan Ali adalah manusia maka Ali adalah fana.”.

Struktur logisnya,

“Jika setiap … (i) … adalah … (ii) … dan … (iii) … adalah … (iv) … maka … (v) … adalah … (vi) …”.

Jika (i) dan (iv) diisi dengan kata benda yang sama, (ii) dan (vi) dengan kata sifat yang sama, dan (iii) dan (v) dengan kata nama yang sama, maka selalu diperoleh suatu pernyataan yang benar. Tetapi kalau ditinjau pernyataan yang lain,

“Suhu di dalam kamar ini adalah 40 derajat Celcius.”

Kebenaran dari pernyataan ini harus didasarkan oleh fakta, jadi pernyataan ini tidaklah selalu benar.

Dalam logika, kebenaran dari suatu pernyataan didasarkan pada kebenaran logisnya. Pernyataan “Besok pagi matahari akan terbit” bukan merupakan suatu kebenaran logis, karena mungkin saja besok pagi hujan atau mendung sehingga matahari tidak terbit. Pernyataan “Jika harga karcis per lembar Rp. 30.000,- , maka harga 5 lembar karcis adalah Rp. 150.000,-“ merupakan suatu keharusan logis. Kebenaran pernyataan ini terkandung dalam pernyataan itu sendiri, dan tidak tergantung pada suatu fakta. Inilah kebenaran dalam matematika, yaitu kebenaran yang relatif.

Dua pernyataan dikatakan logis ekivalen jika kedua pernyataan ini sesuai dalam kebenaran dan kesalahannya dan ini semata – mata didasarkan pada struktur logisnya. Misalnya, “Tidak ada sesuatu zat yang tidak organis dan tidak pula anorganis”. Pernyataan ini sama dengan pernyataan “Setiap zat adalah organis atau anorganis”.

Bukanlah suatu pekerjaan yang mudah untuk menentukan apakah suatu pernyataan logis atau benar ataukah dua pernyataan logis ekivalen, demikian pula apakah suatu pernyataan membawakan suatu pernyataan lain atau tidak. Studi dari hubungan logika matematika dengan pernyataan – pernyataan yang dinyatakan dalam hubungan kalimat ini dinamakan kalkulus proposisi (propositional calculus).

Kalkulus proposisi dapat digunakan untuk menentukan apakah sebuah kalimat adalah valid atau kontradiktif, dan apakah dua buah kalimat merupakan kalimat – kalimat yang ekivalen satu dengan lainnya.

MDAC - MIcrosoft Data Access Component

Microsoft Data Access Component (MDAC) adalah sekumpulan komponen yang merupakan kunci dari teknologi yang membangun aplikasi database. Aplikasi database client server baik itu yang berbasis web ataupun pada suatu LAN dapat menggunakan komponen-komponen ini untuk mengintegrasikan informasi dari berbagai macam sumber data, baik itu yang sifatnya relasional (SQL) maupun data yang tidak relasional komponen-komponen dalam MDAC diantaranya adalah 

1) Microsoft ActiveX Data Object (ADO)

2) OLE DB

3) OPEN Database Conectivity (ODBC)

Gambar berikut ini akan menunjukan secara keseluruhan mengenai arsitektur MDAC dan bagaimana MDAC ini menjadi kunci dakam membangun model UDA (Universal Data Access).

Berikut adalah penjelasan terkait MDAC

1) ActiveXData Object (ADO)

Microsoft ActiveX Data Object (ADO) adalah suatu Application Programming Interface (API) strategi yang khusus digunakan dalam pengaksesan data dan informasi. ADO memberikan cara yang konsisten, pengaksesan data dengan performa tinggi yang mendukung berbagai kepentingan untuk membangun sebuah aplikasi, termasuk dalam pembuatan aplikasi client database, tools, atau browser internet, ADO didesain sedemikian rupa untuk menjadi satu data interface yang dapat digunakan untuk kepentingan single dan client server serta aplikasi berbasis WEB. Keuntungan utama dari ADO adalah kemudahan dalam penggunaan, kecepatan tinggi dan penggunaan memory yang minimal.

Jika kita melihat posisi ADO pada gambar diatas. ADO berada diatas tekhnologi akses data yang lain dan memberikan dukungan data akses terhadap para developer.

ADO memberikan kemudahan interface dalam mengakses OLE DB. ADO menerapkan trafik jaringan secara minimal dan meminimalkan jumlah layar antara fron-end dan sumber data untuk memberikan interface yang ringan tetapi dengan performa yang tinggi. ADO sangat mudah digunakan karena berbasis interface COM automation yang saat ini sudah tersedia pada semua RAD development tools, dan bahasa-bahasa pemrograman di pasaran.

2) OLE DB

OLE DB adalah interface strategis programming pada level sistem untuk mengakses data. OLE DB adalah suatu spesifikasi terbuka yang didesain atas kesuksesan ODBC dengan memberikan suatu standar terbuka untuk mengakses berbagai macam data. ODBC dibuat untuk mengakses database relasional, sedangkan OLE DB di desain data relasional maupun non-relasional.

OLE DB digambarkan sebagai sebuah kumpulan dari COM interface yang mengendalikan berbagai macam service database management system. Interface ini memungkinkan pembuatan suatu komponen software yang digunakan oleh berbagai macam service. Interface OLE DB didesain untuk membantu komponen-komponen agar dapat berintegrasi secara mudah sehingga pembuat komponen OLE DB dapat mebuat komponen OLE DB bagi pengguna denagan kualitas yang baik dan cepat. Sebagai tambahan, OLE DB menawarkan suatu jembatan kepada ODBC untuk membah dukungan kepada driver database ODBC yang banyak ragamnya saat ini.

3) Open Database Connectivity (ODBC)

Interface Microsoft Open Database Connectivity (ODBC) adalah suatu standar industri saat ini dan merupakan komponen dari Mcrosoft Window Open Service Architecture (WOSA). Interface ODBC membuat aplikai-aplikasi dapat mengkases data dari berbagai macam database management system (DBMSs). ODBC mengijinkan interoperabilitas secara maksimal terhadap berbagai macam DBMS hanya dengan melaluisatu interface. Ini dapat dikatakan bahwa suatu aplikasi akan bejalan secara independen. Pengguna aplikasi dapat menambah suatu software komponen yang dinamakan driver, yang mana menciptakan suatu interface antara suatu aplikasi dan suatu DBMS spesifik.

4) OLE Automation

OLE (Object Linking and Embedding) adalah suatu protokol yang memungkinkan adanya komunikasi diantara beberapa aplikasi yang berbeda. Bagian dari OLE yang memungkinkan berbagai aplikasi saling berkomunikasi tersebut dikenal sebagai OLE Automation. Ada dua bentuk OLE  Automation yaitu OLE Automation Client dan OLE Automation Server.

OLE Automation Client dapat mengendalikan aplikasi lain yaitu OLE Automation Server. Dengan kata lain OLE Automation Client adalah suatu aplikasi yang dapat menggunakan berbagai objek beserta fungsi dan prosedurnya yang memang telah disediakan oleh OLE Automation Server. Untuk mengendalikan apikasi berbentuk OLE Automation Server tersebut. Protokol OLE dirancang berdasarkan arsitektur berbasis komponen yang disebut COM (Component Obyek Model)