PERBANDINGAN SISTEM BERORIENTASI OBJEK (OBJECT ORIENTED) DAN SISTEM TERSTRUKTUR

 

 Konsep Dasar Pendekatan Berorientasi Objek

Pendekatan berorientasi objek merupakan suatu teknik atau cara pendekatan dalam melihat permasalahan dan sistem (sistem perangkat lunak. Sistem informasi, atau sistem lainnva). Pendekatan berorientasi objek akan memandang sistem yang akan dikembangkan sebagai suatu kumpulan objek yang berkorespondensi dengan objek-objek dunia nvata. Ada banvak cara untuk mengabstraksikan dan memodelkan objek-objek tersebut, mulai dan abstraksi objek, kelas, hubungan antar kelas sampai abstraksi sistem. Saat mengabstraksikan dan memodelkan objek mi, data dan proses-proses yang dipunyai oleh objek akan dienkapsulasi (dibungkus) menjadi satu kesatuan.

Dalam rekayasa perangkat lunak, konsep pendekatan berorientasi objek dapat diterapkan pada tahap analisis, perancangan, pemrograman, dan pengujian perangkat lunak. Ada berbagai teknik yang dapat digunakan pada masing masing tahap tersebut, dengan aturan dan alat bantu pemodelan tertentu.

Sistem berorientasi objek merupakan sebuah sistem yang dibangun dengan berdasarkan metode berorientasi objek adalah sebuah sistem yang komponennva dibungkus (dienkapsulasi) menjadi kelompok data dan fungsi. Setiap komponen dalam sistem tersebut dapat mewarisi atribut dan sifat dan komponen lainnya. dan dapat berinteraksi satu sama lain.

Karakteristik atau sifat-sifat yang dipunyai sebuah sistem berorientasi objek adalah sebagai berikut:

1.     Abstraksi

prinsip untuk merepresentasikan dunia nyata yang kompleks menjadi satu bentuk model yang sederhana dengan mengabaikan aspek-aspek lain yang tidak sesuai dengan permasalahan.

2.     Enkapsulasi

pembungkusan atribut data dan layanan (operasi-operasi) yang dipunyai objek. untuk menyembunyikan implementasi dan objek sehingga objek lain tidak mengetahui cara kerja-nya.

3.     Pewarisan (inheritance)

yang memungkinkan satu objek mewarisi sebagian atau seluruh definisi dan objek lain sebagai bagian dan dirinya.

4.     Reusabilily

pemanfaatan kembali objek yang sudah didefinisikan untuk suatupermasalahan pada permasalahan lainnya yang melibatkan objek tersebut.

5.     Generalisasi dan Spesialisasi

menunjukkan hubungan antara kelas dan objek yang umum dengan kelas dan objek yang khusus.

6.     Komunikasi Antar Objek

komunikasi antar objek dilakukan lewat pesan (message) yang dikirim dan satu objek ke objek lainnya.

7.     Polymorphism

kemampuan suatu objek untuk digunakan di banyak tujuan yang berbeda dengan nama yang sama sehingga menghemat baris program.

Metodologi Berorientasi Objek

Metodologi berorientasi objek adalah suatu strategi pembangunan perangkat lunak yang mengorganisasikan perangkat lunak sebagai kumpulan objek yang berisi data dan operasi yang diberlakukan terhadapnva. Metodologi berorientasi objek merupakan suatu cara bagaimana sistem perangkat lunak dibangun melalui pendekatan objek secara sistematis. Metode berorientasi objek didasarkan pada penerapan prinsip-prinsip pengelolaan kompleksitas. Metode berorientasi objek meliputi rangkaian aktivitas analisis berorientasi

objek. perancangan berorientasi objek, pemrograman berorientasi objek. Dan pengujian berorientasi objek.

Pada saat ini, metode berorientasi objek banyak dipilih karena metodologi

lama banyak menimbulkan masalah seperti adanya kesulitan pada saat mentransformasi hasil dari satu tahap pengembangan ke tahap berikutnya, misalnya pada metode pendekatan terstruktur, jenis aplikasi yang dikembangkan saat ini berbeda dengan masa lalu. Aplikasi yang dikembangkan pada saat ini sangat beragam (aplikasi bisnis. real-time, utility, dan sebagainya) dengan platform yang berbeda-beda, sehingga menimbulkan tuntutan kebutuhan metodologi pengembangan yang dapat mengakomodasi ke semua jenis aplikasi tersebut.

Keuntungan menggunakan metodologi berorientasi objek adalah sebagai berikut:

1.     meningkatkan produktivitas

karena kelas dan objek yang ditemukan dalam suatu masalah masih dapat dipakai ulang untuk masalah lainnva yang melibatkan objek tersebut (reusable)

2.     kecepatan pengembangan

karena sistem yang dibangun dengan baik dan benar pada saat analisis dan perancangan akan menyebabkan berkurangnva kesalahan pada saat pengkodean kemudahan pemeliharaan

3.     karena dengan model objek, pola-pola yang cenderung tetap dan stabil dapat dipisahkan dan pola-pola yang mungkin sering berubah-ubah adanya konsistensi karena sifat pewarisan dan penggunaan notasi yang sama pada saat analisis, perancangan maupun pengkodean. meningkatkan kualitas perangkat lunak

4.     karena pendekatan pengembangan lebih dekat dengan dunia nyata dan adanya konsistensi pada saat pengembangannva, perangkat lunak yang dihasilkan akan mampu memenuhi kebutuhan pemakai serta mempunyai sedikit kesalahan.

Kelebihan

·       Dibandingkan dengan metode SSAD, OOAD lebih mudah digunakan dalam pembangunan sistem

·       Dibandingkan dengan SSAD, waktu pengembangan, level organisasi, ketangguhan,dan penggunaan kembali (reuse) kode program lebih tinggi dibandingkan dengan metode OOAD (Sommerville, 2000).

·       Tidak ada pemisahan antara fase desain dan analisis, sehingga meningkatkan komunikasi antara user dan developer dari awal hingga akhir pembangunan sistem.

·       Analis dan programmer tidak dibatasi dengan batasan implementasi sistem, jadi desain dapat diformliasikan yang dapat dikonfirmasi dengan berbagai lingkungan eksekusi.

·       Relasi obyek dengan entitas (thing) umumnya dapat di mapping dengan baik seperti kondisi pada dunia nyata dan keterkaitan dalam sistem. Hal ini memudahkan dalam mehami desain (Sommerville, 2000).

·       Memungkinkan adanya perubahan dan kepercayaan diri yang tinggi terhadap kebernaran software yang membantu untuk mengurangi resiko pada pembangunan sistem yang kompleks (Booch, 2007).

·       Encapsliation data dan method, memungkinkan penggunaan kembali pada proyek lain, hal ini akan memperingan proses desain, pemrograman dan reduksi harga.

·       OOAD memungkinkan adanya standarisasi obyek yang akan memudahkan memahami desain dan mengurangi resiko pelaksanaan proyek.

·       Dekomposisi obyek, memungkinkan seorang analis untuk memcah masalah menjadi pecahan-pecahan masalah dan bagian-bagian yang dimanage secara terpisah. Kode program dapat dikerjakan bersama-sama. Metode ini memungkinkan pembangunan software dengan cepat, sehingga dapat segera masuk ke pasaran dan kompetitif. Sistem yang dihasilkan sangat fleksibel dan mudah dalam memelihara.

Kekurangan

·       Pada awal desain OOAD, sistem mungkin akan sangat simple.

·       Pada OOAD lebih fockus pada coding dibandingkan dengan SSAD.

·       Pada OOAD tidak menekankan pada kinerja team seperti pada SSAD.

·       Pada OOAD tidak mudah untuk mendefinisikan class dan obyek yang dibutuhkan sistem.

·       Sering kali pemrogramam berorientasi obyek digunakan untuk melakukan anlisisis terhadap fungsional siste, sementara metode OOAD tidak berbasis pada fungsional sistem.

·       OOAD merupakan jenis manajemen proyek yang tergolong baru, yang berbeda dengan metode analisis dengan metode terstruktur. Konsekuensinya adalah, team developer butuh waktu yang lebih lama untuk berpindah ke OOAD, karena mereka sudah menggunakan SSAD dalam waktu yang lama ( Hantos, 2005).

·       Metodologi pengembangan sistem dengan OOAD menggunakan konsep reuse. Reuse merupakan salah satu keuntungan utama yang menjadi alasan digunakannya OOAD. Namun demikian, tanpa prosedur yang emplisit terhadap reuse, akan sangat sliit untuk menerapkan konsep ini pada skala besar (Hantos, 2005).

 Sekilas Pendekatan Terstruktur

Teknik terstruktur, merupakan pendekatan formal untuk memecahkan masalah-masalah dalam aktivitas bisnis menjadi bagian-bagian kecil yang dapat diatur dan berhubungan untuk kemudian dapat disatukan kembali menjadi satu kesatuan yang dapat dipergunakan untuk memecahkan masalah.

Dalam hubungannya dengan pengembangan sistem informasi dan software aplikasi sistem informasi, pemrograman terstruktur adalah proses yang berorientasi kepada teknik yang digunakan untuk merancang dan menulis program secara jelas dan konsisten. Desain terstruktur merupakan salah satu proses yang berorientasi teknik yang digunakan untuk memilah-milah program besar ke dalam hirarki modul-modul yang menghasilkan program komputer yang lebih kecil agar mudah untuk diimplementasikan dan dipelihara (diubah). Analisis Terstruktur Modern merupakan teknik yang berorientasi kepada proses yang paling populer dan banyak digunakan dewasa ini. Pemodelan data merupakan suatu teknik yang berorientasi kepada data dengan menunjukkan sistem hanya datanya saja terlepas dari bagaimana data tersebut akan diproses atau digunakan untuk menghasilkan informasi.  Rekayasa Informasi merupakan perpaduan dari pemodelan data dan proses, juga memberikan penekanan baru terhadap pentingnya perencanaan sistem informasi.

Ciri-ciri utama teknik terstruktur adalah sebagai berikut:

1.     Merancang berdasar modul

Modularisasi adalah proses yang membagi suatu sistem menjadi beberapa modul yang dapat beroperasi secara independen.

2.     Bekerja dengan pendekatan top-down

Dimulai dari level atas (secara global) kemudian diuraikan sampai ke tingkat modul (rinci).

3.     Dilakukan secara iterasi

Dengan iterasi akan didapat hasil yang lebih baik, terlalu banyak iterasi juga akan menurunkan hasilnya dan menunjukkan bahwa tahap sebelumnya tidak dilakukan dengan baik

4.     Kegiatan dilakukan secara paralel

Pengembangan subsistem-subsistem dapat dilakukan secara paralel, sehingga akan memperpendek waktu pengembangan sistem

Kelebihan

·       Milestone diperlihatkan dengan jelas yang memudahkan dalam manajemen proyek

·       SSAD merupakan pendekatan visual, ini membuat metode ini mudah dimengerti oleh pengguna atau programmer.

·       Penggunaan analisis grafis dan tool seperti DFD menjadikan SSAD menjadikan bagus untuk digunakan.

·       SSAD merupakan metode yang diketahui secara umum pada berbagai industry.

·       SSAD sudah diterapkan begitu lama sehingga metode ini sudah matang dan layak untuk digunakan.

·       SSAD memungkinkan untuk melakukan validasi antara berbagai kebutuhan

·       SSAD relatif simpel dan mudah dimengerti.

Kekurangan

·       SSAD berorientasi utama pada proses, sehingga mengabaikan kebutuhan non-fungsional.

·       Sedikit sekali manajemen langsung terkait dengan SSAD

·       Prinsip dasar SSAD merupakan pengembangan non-iterative (waterfall), akan tetapi kebutuhan akan berubah pada setiap proses.

·       Interaksi antara analisis atau pengguna tidak komprehensif, karena sistem telah didefinisikan dari awal, sehingga tidak adaptif terhadap perubahan (kebutuhan-kebutuhan baru).

·       Selain dengan menggunakan desain logic dan DFD, tidak cukup tool yang digunakan untuk mengkomunikasikan dengan pengguna, sehingga sangat sliit bagi pengguna untuk melakukan evaluasi.

·       Pada SAAD sliit sekali untuk memutuskan ketika ingin menghentikan dekomposisi dan mliai membuat sistem.

·       SSAD tidak selalu memenuhi kebutuhan pengguna.

·       SSAD tidak dapat memenuhi kebutuhan terkait bahasa pemrograman berorientasi obyek, karena metode ini memang didesain untuk mendukung bahasa pemrograman terstruktur, tidak berorientasi pada obyek (Jadalowen, 2002).

Sumber:

http://www.scribd.com/doc/60314795/48/Perbandingan-Pendekatan-OO-dan-Terstruktur

http://supriliwa.wordpress.com/2010/05/07/perbandingan-metode-terstruktrur-dan-obyek-oriented-pada-pengambangan-sistem-informasi/

http://www.ms-room.com/index.php?topic=3789.0

UNIFIED MODELING LANGUAGE (UML)

 

1.     PENGERTIAN UNIFIED MODELING LANGUAGE (UML)

Unified Modeling Language (UML) merupakan bahasa spesifikasi standar untuk mendokumentasikan, memvisualisasikan, menspesifikasikan, dan membangun sistem perangkat lunak. Unified Modeling Language (UML) adalah himpunan struktur dan teknik untuk pemodelan desain program berorientasi objek (OOP) serta aplikasinya. UML adalah metodologi untuk mengembangkan sistem OOP dan sekelompok perangkat (tool) untuk mendukung pengembangan sistem tersebut. Bahasa UML sendiri menggunakan notasi grafis untuk mengekspresikan desain dari proyek perangkat lunak. UML mempermudah penggunanya untuk saling berkomunikasi, mengeksplorasi desain yang potensial, dan memvalidasi desain arsitektural dari perangkat lunak tersebut.

Tujuan utama dari UML adalah:

a.     Menyediakan bahasa visual modeling yang ekspresif dan siap digunakan sehingga penggunanya dapat mengembangkan dan saling berbagi model yang sesuai.

b.     Menyediakan perluasan dan spesialisasi mekanisme untuk memperluas konsep dasar.

c.      Menjadi suatu bahasa pemrograman dan proses pengembangan yang berdiri sendiri (independent).

d.     Menyediakan basis formal untuk memahami bahasa modeling (modeling language) .

e.     Memacu pertumbuhan dari OO tools market.

f.       Mendukung konsep pengembangan level tinggi seperti, kolaborasi, frameworks, pola, dan komponen-komponen.

g.      Mengintegrasikan penggunaan terbaik.

Dengan semakin berkembangnya nilai strategis penggunaan perangkat lunak bagi berbagai macam perusahaan, industri mencari teknik untuk mengotomatisasi produksi perangkat lunak dan untuk meningkatkan kualitas dan mengurangi biaya dan waktu untuk memasarkannya. Teknik tersebut termasuk teknologi komponen, pemrograman visual, pola-pola, dan frameworks. Dunia bisnis juga mencari teknik untuk mengatur kompleksitas dari sistem-sistem bersamaan dengan peningkatan area dan ukuran mereka. Secara khusus, mereka menyadari kebutuhan untuk menyelesaikan masalah-masalah arsitektural yang terus menerus muncul, seperti distribusi fisik, kesamaan pendapat (concurrency), penggandaan, keamanan,  penyeimbangan beban, dan toleransi kesalahan. Sebagai tambahan, perkembangan dari World Wide Web, sembari membuat beberapa hal menjadi lebih ringkas, telah memperburuk problem arsitektural dari hal tersebut. Oleh karena itu, UML diciptakan untuk menjawab kebutuhan untuk menyelesaikan masalah-masalah tersebut.

2. SEJARAH UNIFIED MODELING LANGUAGE (UML)

Bahasa modeling berbasis objek yang teridentifikasi mulai muncul sekitar pertengahan 1970 dan dia akhir era 1980an sebagai berbagai macam metodologist bereksperimen dengan berbagai endekatan yang berbeda terhadap analisa dan desain yang berbasis objek. Jumlah bahasa modeling yang teridentifikasi meningkat dari kurang dari 10 menjadi lebih dari 50 dalam periode 1989 – 1994. Pengguna dari metode OO belum merasa puas dari masing-masing bahasa modeling yang muncul tersebut, dan memicu munculnya “perang metode”. Pada pertengahan era 1990an perulangan dari metode-metode tersebut kembali muncul dan mulai saling menyatukan masing-masing teknik, dan sedikit demi sedikit muncul metode yang lebih menjanjikan.

Perkembangan dari UML sendiri dimulai di akhir 1994 dimana dua orang dari Rational Software Corporation memulai pekerjaan mereka menyatukan metode Booch dan OMT (Object Modeling Technique). Pada musim semi 1995, Ivar Jacobson dan perusahaannya bergabung dengan Rational Software Corp. Dan memasukkan metode OOSE (Object-Oriented Software Engineering).

Sebagai pencipta dari metode Booch, OMT, dan OOSE, Grady Booch, Jim Rumbaugh, dan Ivar Jacobson termotivasi untuk menciptakan gabungan bahasa modeling dengan tiga alasan, yaitu:

1.     Metode-metode tersebut sudah berkembang terhadap satu sama lain secara independen. Tentu saja sangat masuk akal untuk melanjutkan evolusi tersebut secara bersamaan, dan mengeliminasi potensi dari  perbedaan yang tak dibutuhkan yang dapat membingungkan penggunanya.

2.     Dengan menggabungkan semantik-semantik dan notasi, mereka dapat menstabilkan pasar sistem berbasis objek, membiarkan proyek untuk menentukan satu bahasa modeling yang telah berkembang dan membiarkan tool builders tetap fokus untuk menciptakan lebih banyak fitur-fitur yang berguna.

3.     Mereka mengharapkan hasil kolaborasi mereka dapat memicu perbaikan dari tiga metode sebelumnya, membantu mereka menangkap hal-hal yang dipelajari dan menjawab masalah yang tidak bisa ditangani oleh metode-metode mereka yang sebelumnya.

2.1. UML 0.XX

Usaha dari Booch, Rumbaugh, dan Jacobson menghasilkan dokumentasi UML 0.9 dan 0.91 pada bulan juni dan oktober 1996 . selama tahun 1996 tersebut, para pencipta UML diundang dan menerima respond dari komunitas umum. Mereka menyatukan  respond-respond tersebut, dan melihat bahwa atensi tambahan masih dibutuhkan.

Saat Rational Software Corp. Menggabungkan UML, usaha lain juga sedang dilakukan untuk mencapai tujuan yang lebih luas bahasa modeling yang berstandar industri. Pada awal 1995, Jacobson dan Richard Soley (Chief Technology Officer dari OMG) memutuskan untuk mempercepat pencapaian standarisasi dari metode-metode ini. Pada juni 1995, Pertemuan para pencipta metode-metode yang diselenggarakan oleh OMG menghasilkan persetujuan internasional pertama untuk menetapkan standarisasi metode, dibawah pengawasan OMG.

2.2.UML 1.XX

Dalam tahun 1996 tersebut, telah terlihat bahwa beberapa organisasi memandang UML sebagai salah satu bentuk dari strategi bisnis mereka. Request for Proposal (RFP) yang dikeluarkan Object Management Group (OMG) menyediakan katalis bagi organisasi-organisasi tersebut untuk bergabung dan memberikan respon terhadap RFP tersebut. Rational Corp. Menyelenggarakan Konsorsium Rekanan UML  dengan beberapa organisasi yang bersedia menyediakan sumber sumber untuk menciptakan UML 1.0. Organisasi yang paling banyak berkontribusi antara lain: Digital Equipment Corp., HP, i-logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI, dan Unisys. Kolaborasi ini menghasilkan UML 1.0, bahasa modeling yang terdefinisi dengan baik, ekspresif, powerful, dan dapat diaplikasikan secara umum. UML 1.0 diserahkan ke OMG  pada Januari 1997 sebagai hasil dari inisiasi respon RFP.

Pada Januari 1997, IBM, ObjecTime, Platinum Technology Ptech, Taskon, Reich Technologies dan Softeam juga menyerahkan respon terpisah dari RPF kepada OMG. Perusahaan-perusahaan tersebut bergabung ke dalam rekanan UML untuk mengkontribusikan ide-ide mereka bersama dengan seluruh rekanan memproduksi UML 1.1 yang sudah terevisi. Inti dari perilisan UML 1.1 adalah untuk meningkatkan kejelasan dari semantik semantik UML 1.0 dan menggabungkan kontribusi dari rekanan-rekanan yang baru. UML 1.1 diserahkan ke OMG, dan diterima pada musim gugur 1997.

     Sebagai notasi modeling, pengaruh dari notasi OMT mendominasi (contohnya: menggunakan pengkotakan untuk masing-masing kelas dan objek). Walaupun notasi “awan” dari Booch tidak digunakan, kemampuan Booch menspesifikasikan detail desain level rendah tetap digunakan. Notasi  Use case (salah satu langkah/tindakan dalam sistem software) dari Objectory dan notasi komponen dari Booch diintegrasikan dengan notasi lainnya, namun integrasi semantik masih terlihat lemah di UML 1.1 dan tidak diperbaiki dengan benar sampai dengan revisi di UML 2.0.

Konsep dari berbagai macam metode OO juga secara umum terintegrasi dengan UML dengan tujuan agar UML dapat mesuk ke semua metode. Banyak juga yang mengkontribusikan,  dengan pendekatan mereka yang memberi atmosfir terhadap model yang sedang beredar saat itu, termasuk: Tony Wasserman dan Peter Pircher dengan notasi “Object-Oriented Structured Design (OOSD)”, Ray Buhr dengan “ Systems Design with Ada”, Archie Bowen dengan use case dan timing analysis, Paul Ward dengan data analysis, dan David Harel dengan “Statecharts”; bersamaan dengan percobaan untuk memastikan perluasan cakupan terhadap sistem domain real-time. Hasilnya, UML berguna dalam berbagai macam masalah teknik,  dari proses tunggal, aplikasi-aplikasi pengguna tunggal yang bersamaan, sistem terdistribusi, yang membuat UML sangat luas cakupannya.

2.3.UML 2.x

UML telah berkembang secara signifikan sejak beberapa revisi dari UML 1.1 (UML 1.3, 1.4, dan 1.5) memperbaiki shortcomings dan bugs yang ada pada versi UML pertama, diikuti dengan revisi yang cukup besar yang dilakukan OMG pada tahun 2005.

Walaupun UML 2.1 tidak pernah dikeluarkan secara resmi, versi 2.1.1 dan 2.1.2 muncul di 2007, diikuti dengan UML 2.2 pada Februari 2009. Kemudian UML 2.3 diperkenalkan secara resmi pada Mei 2010. Untuk UML 2.4, sampai dengan Maret 2011 masih dalam tahap beta.

Ada 4 bagian dari spesifikasi UML 2.X, yaitu :

1. The Superstrukture, yang menjelaskan notasi dan semantik untuk diagram dan elemen modelnya.
2. The Infrastructure, yang menjelaskan metamodel dasar dimana The Superstructure berbasis.
3. The Object Constraint Language (OCL), untuk menjelaskan aturan dari elemen model.
4. The UML Diagram Interchange, yang menjelaskan bagaimana 2 buah layout diagram UML saling bertukar.

Versi terakhir yang beredar dari standar ini yaitu: UML Superstructure versi 2.3, UML Infrastructure Versi 2.3, OCL versi 2.2, dan UML Diagram Interchange versi 1.0.

Walaupun banyak UML tools yang mendukung fitur terbaru dari UML 2.x, OMG tidak menyediakan fasilitas test untuk menguji kecocokan dengan masing-masingSpesifikasi tersebut.

3. TIPE-TIPE DIAGRAM UML

Masing-masing diagram UML didesain agar para pengembang dan pengguna dpat melihat sistem software dari perspektif yang berbeda dan dalam berbagai level abstraksi. Diagram UML biasanya dibuat dengan visual modeling tools termasuk yang berikut:

1. Diagram Use Case (Use Case Diagram), menunjukan hubungan antara aktor dan use cases
2. Diagram Kelas, (Class Diagram), menunjukkan struktur kelas model dan isinya menggunakan elemen desain seperti kelas-kelas, paket, dan objek. Diagram ini juga menunjuk hubungan seperti peraturan,  warisan, asosiasi, dan lainnya
3. Diagram Interaksi (Interaction Diagrams), yang terbagi menjadi dua, yaitu:

1.     Diagram Urutan (Sequence Diagram), menunjukkan urutan-urutan dari objek yang berpartisipasi dalam interaksi. Diagram ini mengandung dimensi vertikal dan horizontal.

2.     Diagram Kolaborasi (Collaboration Diagram), menunjukan interaksi yang terorganisir di sekitar objek dan garis hubungan antara satu dan yang lainnya.

4. Diagram Kondisi (State Diagram), menunjukkan urutan kondisi dari objek yang mengalami interaksi beserta respon dan tindakannya.
5. Diagram Aktifitas (Activity Diagram), menunjukkan diagram kondisi yang spesial dimana kondisi yang terjadi hampir semuanya berupa tindakan dan hampir semua transisinya dipicu oleh penyelesaian tindakan dari kondisi sumbernya. Diagram ini fokus terhadap aliran dari proses internal.
6. Diagram Fisik (Physical Diagrams), yang terbagi 2 yaitu:

1.     Diagram Komponen (Component Diagram), menunjukkan struktur paket level tinggi dari kode itu sendiri. Ketergantungan antar komponen juga ditunjukkan, termasuk kode sumber komponen, kode binary componen, dan komponen yang dapat di eksekusi. Beberapa komponen muncul pada waktu pengumpulan, penghubungan, dan saat pemakaian lebih dari satu kali.

2.     Diagram Persiapan (Deployment Diagram), menunjukkan konfigurasi dari elemen pemrosesan run-time dan komponen-komponenin software, proses, dan objek yang ada padanya.  Bagian Komponen software tesebut mewakili manifestasi run-time dari unit-unit kode.

 

Sumber :

http://en.wikipedia.org/wiki/Unified_Modeling_Language

http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/index.htm

http://www.uml.org/

Sastra, Dalam Perkembangan Budaya dan Teknologi

    Budaya merupakan salah satu bagian yang tidak terpisahkan dari kehidupan manusia.  Salah satu hasil dari pembentukan dan pengekspresian suatu budaya adalah dengan adanya bahasa.  Bahasa merupakan syarat mutlak untuk terbentuknya suatu komunikasi.  Bahasa memerlukan suatu media agar pesan yang terkandung di dalamnya dapat tersampaikan dengan baik. Bahasa secara lisan adalah contoh yang paling sederhana.

    Seiring perkembangan jaman dan teknologi, muncul berbagai macam media penyampaian bahasa.  Sastra adalah contoh salah satu 'bahasa' yang  di dalamnya terkandung  suatu seni dan budaya.  Bila pada jaman dulu, sastra disampaikan Hanya secara lisan, maka pada perkembangannya sastra mulai dituangkan secara tertulis, dan karena kemajuan teknologi saat ini perkembangan sastra masing-masing budaya dapat diketahui dan diakses siapa saja.

    Salah satu contoh perkembangan sastra akibat perkembangan zaman dan teknologi dapat dilihat di salah satu media sosial yang terkenal yaitu twitter. twitter merupakan situs mikroblogging dimana penggunanya dapat menuliskan sesuatu yang terbatas dalam 140 karakter huruf. Di sini, saya menemukan satu akun bernama fiksimini (@fiksimini) yang memuat suatu cerita yang tertulis tidak lebih dari 140 karakter. fiksimini memuat ulang tulisan yang cukup baik dari para pengikut akunnya, agar dapat dilihat oleh pengikut akun yang lainnya.

    Kemunculan salah satu bentuk sastra ini tidak terlepas dari  peran manusia itu sendiri sebagai subjeknya. Perkembangan teknologi merupakan tuntutan perkembangan budaya manusia. Munculnya televisi,komputer,terlebih lagi internet, benar-benar membawa kehidupan manusia ke suatu tahap yang tidak terbayangkan sebelumnya.

      Membicarakan mengenai dampak internet,pasti akan muncul berbagai jawaban pro dan kontra terhadap hal ini,tergantung darimana kita memandang dan menggunakan internet itu sendiri. Tapi tidak dipungkiri, adanya internet dapat merubah suatu budaya seseorang,sekelompok orang di suatu lingkungan masayarakat,  bahkan di suatu negara. 

    Hal inilah yang perlu dipahami bagi semua mahasiswa yang belajar dalam bidang teknologi informasi.  Komputer,internet,dan televisi hanyalah sarana semata.  Tapi pemahaman akan budaya,terutama budaya bangsa sendiri sangat penting sehingga nantinya kita tidak akan terpengaruh. Manusia yang mengendalikan media,bukan kita yang dikendalikan media.Karena kitalah pencipta dari media tersebut.    
   
   

Rapid Prototyping

Prototyping

Prototyping adalah proses membangun sebuah model dari suatu sistem .  Dalam sistem informasi, prototipe digunakan untuk membantu desainer mengekpresikan ide desain awal sistem informasi yang intuitif dan mudah dimengerti dengan cepat, tanpa perlu memikirkan pengkodean program yang rumit. Dalam pembuatan prototype diterapkan metode UCD ( User Centered Design ) untuk memenuhi kebutuhan user

Prototyping memberikan fleksibilitas bagi desainer untuk membuat berbagai model dasar suatu system tanpa menyita banyak waktu dan biaya.

Dengan menggunakan prototype, desainer dapat melihat feedback dari pengguna untuk memaksimalkan pengerjaan system sehingga tidak perlu lagi melakukan perubahan radikal saat system selesai dikerjakan.

Rapid Prototyping

Rapid prototyping sendiri merupakan proses pemodelan sederhana dari suatu system, mereview prototype system dari para pengguna dan stakeholder untuk medapatkan feedback yang berguna untuk memperbaiki system tersebut. Proses ini dilakukan berulang (rapid) untuk memaksimal desain akhir dan untuk mengurangi perubahan pada tahap pengerjaan system.

Rapid prototyping melibatkan sejumlah iterasi dari proses berikut:

• Prototype. yaitu menerjemahkan keinginan pengguna dalam bentuk mock-up yang didesain mendekati keinginan pengguna.
• Peninjauan (Review). Mengevaluasi feedback dari user apakah prototype yang dibuat memenuhi kebutuhan dan harapan mereka.
• Perbaikan (Refine). Melakukan penyempurnaan atau perbaikan berdasarkan feedback dari pengguna.

sumber: http://www.smashingmagazine.com/wp-content/uploads/2010/05/prototype-review-refine.jpg

Use Case Diagram

Use-case diagram merupakan model diagram UML yang digunakan untuk menggambarkan requirementfungsional yang diharapkan dari sebuah sistem. Use-case diagram menekankan pada “siapa” melakukan “apa” dalam lingkungan sistem perangkat lunak akan dibangun. Use-case diagram sebenarnya terdiri dari dua bagian besar; yang pertama adalah use case diagram (termasuk gambar use case dependencies) dan use case description.

Use-case diagram adalah gambaran graphical dari beberapa atau semua actor, use-case, dan interaksi diantara komponen-komponen tersebut yang memperkenalkan suatu sistem yang akan dibangun. Use-case diagram menjelaskan manfaat suatu sistem jika dilihat menurut pandangan orang yang berada di luar sistem. Diagram ini menunjukkan fungsionalitas suatu sistem atau kelas dan bagaimana sistem tersebut berinteraksi dengan dunia luar.

Use-case diagram dapat digunakan selama proses analisis untuk menangkap requirement system dan untuk memahami bagaimana sistem seharusnya bekerja. Selama tahap desain, use-case diagram berperan untuk menetapkan perilaku (behavior) sistem saat diimplementasikan. Dalam sebuah model mungkin terdapat satu atau beberapa use-case diagram. Kebutuhan atau requirements system adalah fungsionalitas apa yang harus disediakan oleh sistem kemudian didokumentasikan pada model use-case yang menggambarkan fungsi sistem yang diharapkan (use-case), dan yang mengelilinginya (actor), serta hubungan antara actor dengan use-case(usecase diagram) itu sendiri.

• Use case class digunakan untuk memodelkan dan menyatakan unit fungsi/layanan yang disediakan oleh sistem (or bagian sistem: subsistem atau class) ke pemakai. 
• Use case dapat dilingkupi dengan batasan sistem yang diberi label nama sistem. 
• Use case adalah sesuatu yang menyediakan hasil yang dapat diukur ke pemakai atau sistem eksternal.  

Karakteristik:

• Use cases adalah interaksi atau dialog antara sistem dan actor, termasuk pertukaran pesan dan tindakan yang dilakukan oleh sistem. 
• Use cases diprakarsai oleh actor dan mungkin melibatkan peran actor lain. Use cases harus menyediakan nilai minimal kepada satu actor. 
• Use cases bisa memiliki perluasan yang mendefinisikan tindakan khusus dalam interaksi atau use case lain mungkin disisipkan. 
• Use case class memiliki objek use case yang disebut skenario. Skenario menyatakan urutan pesan dan tindakan tunggal. 

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. 

 

Fungsi Aktivity Diagram : 

• Menggambarkan proses bisnis dan urutan aktivitas dalam sebuah proses 
• Dipakai pada business modeling untuk memperlihatkan urutan aktifitas proses bisnis 
• Struktur diagram ini mirip flowchart atau Data Flow Diagram pada perancangan terstruktur 
• Sangat bermanfaat apabila kita membuat diagram ini terlebih dahulu dalam memodelkan sebuah proses untuk membantu memahami proses secara keseluruhan 
• Activity Diagram dibuat berdasarkan sebuah atau beberapa use case pada use case diagram 

 

Elemen-Elemen Activity Diagram :

• Swimlanes, menunjukkan siapa yang bertanggung jawab melakukan aktivitas dalam suatu diagram 
• Activities State, adalah kegiatan dalam aliran kerja 
• Action State, adalah langkah-langkah dalam sebuah activity. Action bisa terjadi saat memasuki activity, meningggalkan activity, saat di dalam activity, atau pada event yang spesifik 
• Business object, adalah entitas-entitas yang digunakan dalam aliran kerja 
• Transition, menunjukkan bagaimana aliran kerja itu berjalan dari satu aktivitas ke aktivitas lainnya 
• Decision point, menunjukkan dimana sebuah keputusan perlu dibuat dalam aliran kerja 
• Syncronization, menunjukkan dua atau lebih langkah dalam aliran kerja berjalan secara serentak à Fork dan Join 
• Start state, menunjukkan dimana aliran kerja itu dimulai 
• End state, menunjukkan dimana aliran kerja itu berakhir 

Class Diagram

Class diagram adalah sebuah class yang menggambarkan struktur dan penjelasan class, paket, dan objek serta hubungan satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain. Class diagram juga menjelaskan hubungan antar class dalam sebuah sistem yang sedang dibuat dan bagaimana caranya agar mereka saling berkolaborasi untuk mencapai sebuah tujuan.

Class juga memiliki 3 area pokok (utama) yaitu nama, atribut, dan operasi. Nama berfungsi untuk member identitas pada sebuah kelas, atribut fungsinya adalah untuk member karakteristik pada data yang dimiliki suatu objek di dalam kelas, sedangkan operasi fungsinya adalah memberikan sebuah fungsi ke sebuah objek. Dalam mendefinisikan metode yang ada di dalam kelas harus diperhatikan yang namanya Cohesion dan Coupling, Cohesion adalah ukuran keterkaitan sebuah instruksi di sebuah metode, Coupling adalah ukuran keterkaitan antar metode. Di dalam class diagram terdapat hubungan antar kelas secara konseptual, yang disebut Relasi antar Class, di UML disediakan macam-macam relasi antar Class, diantaranya: Asosiasi (Hubungan statis antar kelas), Agregasi (hubungan dari keseluruhan objek), Generalisasi (relasi beberapa subkelas ke super kelas), dependency (keterhubungan tiap kelas.)

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.

 
Hubungan Antar Class 

• Asosiasi, yaitu hubungan statis antar class. Umumnya menggambarkan class yang memiliki atribut berupaclass lain, atau class yang harus mengetahui eksistensi class lain. Panah navigability menunjukkan arahquery antar class. 
• Agregasi, yaitu hubungan yang menyatakan bagian (“terdiri atas..”). 
• 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 dariclass yang diwarisinya. Kebalikan dari pewarisan adalah generalisasi. 
• 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.