Thursday, June 6, 2013

Konsep Pemodelan Data, Pemodelan Proses & UML

Pemodelan Data Pemodelan, Proses DanUML

Abstrak

Model data dalam rekayasa perangkat lunak adalah proses menciptakan sebuah model data dengan menerapkan model data resmi deskripsi dengan menggunakan teknik pemodelan data.
Desain berorientasi objek adalah proses perencanaan sistem objek berinteraksi untuk tujuan pemecahan masalah perangkat lunak. Ini adalah salah satu pendekatan untuk merancang perangkat lunak.

Pendahuluan

Sebuah objek berisi data dan prosedur enkapsulasi dikelompokkan bersama-sama untuk mewakili suatu entitas. The ‘object interface’, bagaimana benda dapat berinteraksi dengan, juga didefinisikan. Sebuah program berorientasi objek digambarkan oleh interaksi benda-benda ini. Desain berorientasi objek adalah disiplin mendefinisikan objek dan interaksi mereka untuk memecahkan masalah yang diidentifikasi dan didokumentasikan selama analisis berorientasi objek.
Dari perspektif bisnis, Object Oriented Design mengacu pada objek yang membentuk bisnis itu. Sebagai contoh, dalam sebuah perusahaan tertentu, objek bisnis dapat terdiri dari orang-orang, file data dan tabel database, artefak, peralatan, kendaraan, dll. Berikut ini adalah deskripsi kelas berbasis subset dari desain berorientasi objek, yang tidak termasuk objek prototipe pendekatan berbasis objek di mana tidak biasanya diperoleh dengan kelas tapi oleh instancing kloning lain (prototipe) obyek.

Landasan Teori

1. Metode analisis dan perancangan sistem informasi sudah mencapai tiga generasi;
a. Generasi pertama disebut metode tradisional
b. Generasi kedua disebut metode terstruktur.
c. Generasi ketiga Object Oriented Analysis and Design
2. Object modeling merupakan teknik untuk mengidentifikasi objek serta hubungan di antaraobjek yang berada dalam lingkungan sistem.
3. Object-oriented analysis merupakan salah satu cara yang sistematis untuk melakukan analisisberdasarkan pendekatan objek. object-oriented analysis (OOA) digunakan untuk :
a. mempelajari objek-objek agar objek-objek tersebut dapat digunakan atau disesuaikan kembali untuk kepentingan pengembangan yang baru.
b. mendefinisikan objek-objek baru atau yang telah diubah, yang akan dikombinasikan dengan objek-objek yang sudah menjadi suatu aplikasi bisnis yang berdaya guna tinggi.
4. Manfaat dari Object-oriented Analysis
a. Objek-objek memfasilitasi modularity dan encapsulation.
b. Classes mendukung konsep reusability.
c. Abstraction berarti objek-objek akan dianalisa sampai mereka benar-benar unik.
d. Persistence artinya keberadaan setiap class dan object adalah permanent dan dapat digunakan selama sistem berjalan.
5. Karakteristik dari OOAD adalah Inheritance, Encapsulation dan Polymorphism.
6. UML merupakan singkatan dari Unified Modeling Language yang merupakan sebuah bahasa yang dijadikan standar untuk mengvisualisasikan rancangan serta mendokumentasikan hasil analisis dan perancangan sistem.
7. Diagram-diagram dikenal didalam penggunaan UML adalah sebagai berikut:
  • Use Case Diagram
  • Class Diagram
  • Object Diagram
  • Sequence Diagram
  • Collaboration Diagram
  • State Chart Diagram
  • Activity Diagram
  • Component Diagram
  • Deployment Diagram
6. Jadi dapat disimpulkan bahwa objek merupakan entitas yang mempunyai identitas, state dan behavior. Tiga hal yang harus diperhatikan dalam mendefinisikan objek, yaitu:
  • • Jenis-jenis dari objek.
  • • Objek harus memiliki attributes.
  • • Objek harus memiliki behavior.
7. Attributes (atribut) merupakan data yang merepresentasikan karakteristik yang unik
mengenai sebuah objek.
8. Behavior mengacu pada hal-hal apa saja yang dapat dilakukan oleh objek sehingga
menyebabkan function (dari objek) melakukan suatu aksi terhadap data atau atribut (dari
objek).
9. Class merupakan sekumpulan objek yang memiliki atribut dan behavior yang sama.
Struktur dari Class ada 3, yaitu :
  • Generalization/Specialization
  • Association
  • Aggregation
10. Supertype class merupakan class yang menjadi tempat penyimpanan attributes yang
dimiliki bersama (common) oleh satu atau lebih subtype objek.
11. Subtype class merupakan class yang diwariskan beberapa common attribute oleh
supertype class, yang kemudian menambahkan atribut unik lainnya pada subtype itu
sendiri.
12. Object/class relationship merupakan hubungan bisnis alami yang terjadi pada satu atau
lebih objek atau class.
13. Objek-objek atau classes dibuat dari objek/class lainnya. Hubungan yang seperti ini
disebut sebagai aggregation. Ada dua jenis aggregation, yaitu;
  • composition
  • shared.
14. Sebuah message dapat disampaikan ketika satu objek terlibat dengan objek lainnya
melalui behavior untuk melakukan aksi yang sama.

Isi Pembahasan

Data modeling

Model data dalam rekayasa perangkat lunak adalah proses menciptakan sebuah model data dengan menerapkan model data resmi deskripsi dengan menggunakan teknik pemodelan data.

Overview

Model data adalah metode yang digunakan untuk menentukan dan menganalisis data persyaratan yang dibutuhkan untuk mendukung proses bisnis dari sebuah organisasi.Persyaratan data yang dicatat sebagai model data konseptual dengan data terkait definisi.Sebenarnya pelaksanaan model konseptual yang disebut model data logis. Untuk menerapkan salah satu model data konseptual mungkin memerlukan beberapa model data logis. Pemodelan data tidak hanya mendefinisikan elemen data, tetapi struktur dan hubungan di antara mereka. Data model teknik dan metodologi yang digunakan untuk model data dalam standar, konsisten, dapat diprediksi cara untuk mengelolanya sebagai sumber daya. Penggunaan standar pemodelan data sangat disarankan untuk semua proyek yang membutuhkan standar sarana untuk mendefinisikan dan menganalisis data dalam sebuah organisasi, misalnya data menggunakan model: untuk mengelola data sebagai sumber daya: untuk integrasi sistem informasi: untuk merancang database/data gudang (repositori data alias) Pemodelan data dapat dilakukan pada berbagai jenis proyek dan dalam berbagai fase proyek.Model data bersifat progresif, tidak ada yang namanya data akhir model untuk bisnis atau aplikasi. Sebaliknya model data harus dianggap sebagai dokumen hidup yang akan berubah sebagai respons terhadap perubahan bisnis. Model data idealnya harus disimpan dalam repositori sehingga mereka dapat diambil, dikembangkan, dan diedit dari waktu ke waktu.Whitten (2004) ditetapkan dua jenis data model: Pemodelan data strategis: Ini adalah bagian dari penciptaan sistem informasi strategi, yang mendefinisikan visi dan keseluruhan sistem informasi arsitektur untuk didefinisikan. Informasi teknik adalah suatu metodologi yang mencakup pendekatan ini.
Model data selama analisis sistem: Dalam analisis sistem model data logika diciptakan sebagai bagian dari pengembangan database baru. Model data juga merupakan teknik untuk membuat rincian kebutuhan bisnis untuk database.Hal ini kadang-kadang disebut database model karena model data pada akhirnya diterapkan dalam database.

Data modeling topics

Data models

Dukungan model data data dan sistem komputer dengan memberikan definisi dan format data.Jika hal ini dilakukan secara konsisten di seluruh sistem kemudian kompatibilitas data dapat dicapai. Jika struktur data yang sama digunakan untuk menyimpan dan mengakses data maka aplikasi yang berbeda dapat berbagi data. Hasil ini ditunjukkan di atas. Namun, sistem dan antarmuka seringkali lebih mahal dari yang seharusnya, untuk membangun, mengoperasikan, dan memelihara. Mereka mungkin juga menghambat bisnis daripada mendukungnya. Sebuah penyebab utama adalah bahwa kualitas model data yang dilaksanakan dalam sistem dan interface adalah miskin. Aturan bisnis, khusus untuk bagaimana hal-hal yang dilakukan di tempat tertentu, sering tetap dalam struktur model data. Ini berarti bahwa perubahan kecil dalam cara bisnis dilakukan menyebabkan perubahan besar pada sistem komputer dan interface. Jenis entitas sering tidak teridentifikasi, atau keliru diidentifikasi. Hal ini dapat mengakibatkan replikasi data, struktur data, dan fungsi, bersama dengan biaya petugas yang duplikasi dalam pembangunan dan pemeliharaan. Data model untuk sistem yang berbeda secara sewenang-wenang berbeda. Hasil ini adalah interface yang kompleks diperlukan antara sistem yang berbagi data. Interface ini dapat menjelaskan antara 25-70% dari biaya sistem saat ini. Data tidak dapat dibagi secara elektronik dengan pelanggan dan pemasok, karena struktur dan arti data yang belum standar. Sebagai contoh, desain teknik data dan gambar untuk pabrik proses masih kadang-kadang dipertukarkan di atas kertas. Alasan untuk masalah ini adalah kurangnya standar yang akan memastikan bahwa model-model data yang baik akan memenuhi kebutuhan bisnis dan konsisten.

Conceptual, logical and physical schemes

Sebuah contoh model data dapat menjadi salah satu dari tiga jenis menurut ANSI pada tahun 1975:
Skema konseptual: menggambarkan semantik dari sebuah domain, menjadi ruang lingkup model. Sebagai contoh, mungkin model bidang minat dari sebuah organisasi atau industri. Ini terdiri dari kelas entitas, mewakili hal-hal signifikansi dalam domain, dan hubungan pernyataan tentang asosiasi antara kelas entitas pasang. Sebuah skema konseptual menentukan jenis fakta atau proposisi yang dapat dinyatakan dengan menggunakan model. Dalam pengertian itu, ia mendefinisikan ekspresi yang dibolehkan dalam buatan ‘bahasa’ dengan lingkup yang dibatasi oleh ruang lingkup model. Logis skema: menggambarkan semantik, seperti yang diwakili oleh manipulasi data tertentu teknologi. Ini terdiri dari deskripsi tabel dan kolom, kelas berorientasi objek, dan XML tag, antara lain. Fisik skema: menggambarkan sarana fisik dimana data disimpan. Hal ini berkaitan dengan partisi, CPU, tablespace, dan sejenisnya. Arti penting dari pendekatan ini, menurut ANSI, adalah bahwa hal itu memungkinkan tiga perspektif relatif independen satu sama lain. Teknologi penyimpanan dapat berubah tanpa mempengaruhi baik logis atau model konseptual. Tabel / kolom struktur dapat berubah tanpa (harus) mempengaruhi model konseptual. Dalam setiap kasus, tentu saja, struktur harus tetap konsisten dengan model yang lain. Tabel / kolom struktur mungkin berbeda dari terjemahan langsung dari kelas entitas dan atribut, tetapi harus akhirnya melaksanakan tujuan dari entitas konseptual struktur kelas. Fase-fase awal dari banyak proyek-proyek pengembangan perangkat lunak menekankan desain sebuah model data konseptual. Desain seperti itu dapat dirinci ke dalam model data logis. Dalam tahap-tahap selanjutnya, model ini dapat diterjemahkan ke dalam model data fisik. Namun, juga memungkinkan untuk menerapkan model konseptual secara langsung.

Data modeling process

Dalam konteks Proses Bisnis Integrasi, lihat gambar, model data dalam database akan menghasilkan generasi. Ini melengkapi model proses bisnis, yang menghasilkan program aplikasi untuk mendukung proses bisnis. Desain database yang sebenarnya adalah proses menghasilkan suatu model data rinci database. Model data logis ini berisi semua yang diperlukan logis dan pilihan desain fisik dan parameter penyimpanan fisik yang diperlukan untuk menghasilkan desain dalam Data Definition Language, yang kemudian dapat digunakan untuk membuat sebuah database. Sebuah model data dikaitkan sepenuhnya berisi rincian atribut untuk setiap entitas. Istilah desain database dapat digunakan untuk menggambarkan beberapa bagian dari rancangan sistem database secara keseluruhan. Pada prinsipnya, dan paling benar, dapat dianggap sebagai desain logis dari struktur data dasar yang digunakan untuk menyimpan data. Dalam model relasional ini adalah tabel dan tampilan. Dalam sebuah database Obyek entitas dan hubungan peta langsung ke kelas dan nama objek hubungan. Namun, istilah desain database juga dapat digunakan untuk diterapkan pada proses perancangan keseluruhan, bukan hanya struktur data dasar, tetapi juga bentuk dan query yang digunakan sebagai bagian dari keseluruhan aplikasi basis data dalam Database Management System atau DBMS. Dalam proses antarmuka sistem merupakan 25% sampai 70% dari biaya pengembangan dan dukungan sistem saat ini. Alasan utama biaya ini adalah bahwa sistem ini tidak berbagi data model yang umum. Jika data model yang dikembangkan pada sistem dasar sistem, maka bukan hanya merupakan analisis yang sama diulang di daerah-daerah tumpang tindih, namun analisis lebih lanjut harus dilakukan untuk menciptakan antarmuka antara mereka. Kebanyakan sistem berisi komponen dasar yang sama, dibangun kembali untuk tujuan tertentu. Sebagai contoh berikut ini dapat menggunakan model klasifikasi dasar yang sama sebagai komponen: Bahan Catalogue, Spesifikasi produk dan Merek, Spesifikasi peralatan. Komponen yang sama dipugar karena kita tidak punya cara untuk mengatakan mereka adalah hal yang sama.

Modeling methodologies

Model data informasi merupakan bidang yang diminati. Meskipun ada banyak cara untuk membuat model data, menurut Len Silverston (1997) hanya dua model metodologi menonjol, top-down dan bottom-up: Bottom-up model sering hasil dari usaha rekayasa ulang. Mereka biasanya mulai dengan bentuk-bentuk struktur data yang ada, aplikasi bidang pada layar, atau laporan. Model ini biasanya fisik, aplikasi-spesifik, dan tidak lengkap dari perspektif perusahaan. Mereka mungkin tidak mempromosikan berbagi data, terutama jika mereka dibangun tanpa merujuk ke bagian lain dari organisasi. Top-down model data logis, di sisi lain, diciptakan dalam cara yang abstrak dengan mendapatkan informasi dari orang-orang yang mengetahui wilayah subjek. Sebuah sistem mungkin tidak melaksanakan semua entitas dalam sebuah model logis, tapi model berfungsi sebagai titik acuan atau template. Kadang-kadang model dibuat dalam campuran dari dua metode: dengan mempertimbangkan kebutuhan data dan struktur aplikasi dan dengan konsisten referensi subjek-model daerah.Sayangnya, di banyak lingkungan perbedaan antara data logis model dan model data fisik adalah kabur. Selain itu, beberapa alat KASUS tidak membuat perbedaan antara logis dan model data fisik.

Entity relationship diagrams

Ada beberapa notasi untuk data modeling. Model yang sebenarnya sering disebut “model hubungan Entity”, karena menggambarkan data dalam bentuk entitas dan hubungan yang digambarkan dalam data. [3] An-model hubungan entitas (ERM) adalah representasi konseptual abstrak data terstruktur. Entitas-hubungan model adalah sebuah model database relasional metode, yang digunakan dalam rekayasa perangkat lunak untuk menghasilkan jenis model data konseptual (atau model data semantik) dari sistem, seringkali sebuah database relasional, dan ketentuannya secara top-down. Model ini digunakan dalam tahap pertama desain sistem informasi selama analisis persyaratan untuk menggambarkan kebutuhan informasi atau jenis informasi yang akan disimpan dalam database. Teknik pemodelan data dapat digunakan untuk menggambarkan setiap ontologi (yaitu gambaran dan klasifikasi istilah yang digunakan dan hubungan mereka) untuk alam semesta tertentu yaitu wacana daerah tertentu. Beberapa teknik telah dikembangkan untuk desain model data. Sementara data panduan metodologi ini modelers dalam pekerjaan mereka, dua orang yang berbeda dengan menggunakan metodologi yang sama akan sering muncul dengan hasil yang sangat berbeda. Paling menonjol adalah:
  1. Bachman diagram
  2. Notasi Barker
  3. Chen
  4. Data Vault Modeling
  5. Extended Backus-Naur form
  6. IDEF1X
  7. Pemetaan objek-relasional
  8. Peran object Modeling
  9. Relational Model

Generic data modeling

Generic generalisasi model data dari model data konvensional. Mereka menetapkan standar tipe hubungan umum, bersama dengan hal-hal yang mungkin berhubungan dengan tipe hubungan seperti itu. Yang dimaksud dengan model data umum mirip dengan definisi bahasa alami. Sebagai contoh, sebuah model data generik dapat menentukan jenis hubungan seperti ‘klasifikasi hubungan’, sebagai hubungan biner antara seorang individu dan hal-hal semacam (kelas) dan ‘keseluruhan bagian-hubungan’, sebagai hubungan biner antara dua hal, satu dengan peran bagian, yang lain dengan peran keseluruhan, tanpa memandang jenis hal-hal yang terkait. Diberikan daftar extensible kelas, ini memungkinkan klasifikasi dari setiap individu untuk menentukan hal dan seluruh bagian-hubungan untuk setiap individu objek. Dengan standardisasi dari daftar extensible hubungan jenis, model data umum memungkinkan ekspresi dalam jumlah tidak terbatas jenis fakta dan akan mendekati kemampuan bahasa alam. Model data konvensional, di sisi lain, ada yang tetap dan terbatas ruang lingkup domain, karena Instansiasi (penggunaan) dari model seperti itu hanya memungkinkan ekspresi dari jenis fakta yang telah ditetapkan dalam model.
Semantic data modeling
Struktur data logis dari suatu DBMS, apakah hirarkis, jaringan, atau relasional, tidak dapat sepenuhnya memenuhi persyaratan untuk definisi konseptual data karena dibatasi dalam ruang lingkup dan condong ke strategi pelaksanaan yang digunakan oleh DBMS. Data semantik model. Oleh karena itu, kebutuhan untuk mendefinisikan data dari pandangan konseptual telah menyebabkan pengembangan teknik pemodelan data semantik. Yaitu, teknik untuk menentukan makna data dalam konteks hubungan dengan data lainnya. Seperti diilustrasikan pada gambar dunia nyata, dalam hal sumber daya, ide, kegiatan, dll, yang secara simbolis didefinisikan dalam data fisik toko. Sebuah model data semantik adalah sebuah abstraksi yang mendefinisikan bagaimana simbol-simbol yang disimpan berhubungan dengan dunia nyata.Dengan demikian, model harus benar-benar representasi dari dunia nyata. Sebuah model data semantik dapat digunakan untuk melayani berbagai keperluan, seperti: perencanaan sumber daya data pembangunan database shareable evaluasi vendor perangkat lunak integrasi database yang sudah ada Tujuan menyeluruh dari data semantik model adalah untuk menangkap lebih banyak makna data dengan mengintegrasikan konsep-konsep relasional dengan konsep-konsep abstraksi yang lebih kuat dikenal dari bidang Kecerdasan Buatan. Idenya adalah untuk memberikan tingkat tinggi model primitif sebagai bagian integral dari model data agar dapat memfasilitasi representasi dari situasi dunia nyata.

Object-oriented design

Desain berorientasi objek adalah proses perencanaan sistem objek berinteraksi untuk tujuan pemecahan masalah perangkat lunak. Ini adalah salah satu pendekatan untuk merancang perangkat lunak.

Overview

Sebuah objek berisi data dan prosedur enkapsulasi dikelompokkan bersama-sama untuk mewakili suatu entitas. The ‘object interface’, bagaimana benda dapat berinteraksi dengan, juga didefinisikan. Sebuah program berorientasi objek digambarkan oleh interaksi benda-benda ini. Desain berorientasi objek adalah disiplin mendefinisikan objek dan interaksi mereka untuk memecahkan masalah yang diidentifikasi dan didokumentasikan selama analisis berorientasi objek. Dari perspektif bisnis, Object Oriented Design mengacu pada objek yang membentuk bisnis itu. Sebagai contoh, dalam sebuah perusahaan tertentu, objek bisnis dapat terdiri dari orang-orang, file data dan tabel database, artefak, peralatan, kendaraan, dll. Berikut ini adalah deskripsi kelas berbasis subset dari desain berorientasi objek, yang tidak termasuk objek prototipe pendekatan berbasis objek di mana tidak biasanya diperoleh dengan kelas tapi oleh instancing kloning lain (prototipe) obyek.

Object-oriented design topics

Input (sources) for object-oriented design

Input untuk desain berorientasi obyek ini disediakan oleh output dari analisis berorientasi objek. Sadarilah bahwa sebuah output artefak tidak perlu sepenuhnya dikembangkan untuk melayani sebagai masukan dari desain berorientasi objek; analisis dan desain dapat terjadi secara paralel, dan dalam praktiknya hasil dari satu kegiatan dapat memberi makan yang lain dalam siklus umpan pendek melalui iteratif proses. Baik analisis dan desain dapat dilakukan secara bertahap, dan artefak dapat tumbuh terus, bukan sepenuhnya dikembangkan dalam satu kesempatan. Beberapa masukan artefak khas untuk desain berorientasi objek adalah:
* Konseptual model: model konseptual adalah hasil dari analisis berorientasi objek, ia menangkap konsep-konsep dalam masalah domain. Model konseptual eksplisit dipilih untuk menjadi independen dari rincian pelaksanaan, seperti concurrency atau penyimpanan data.
* Gunakan kasus: kasus Gunakan deskripsi urutan peristiwa itu, diambil bersama-sama, mengarah pada sistem melakukan sesuatu yang bermanfaat. Setiap use case menyediakan satu atau lebih skenario yang menyampaikan bagaimana sistem harus berinteraksi dengan para pengguna yang disebut aktor untuk mencapai tujuan bisnis tertentu atau fungsi. Gunakan aktor kasus mungkin end user atau sistem lain. Dalam banyak kasus penggunaan keadaan dijabarkan lebih lanjut dalam kasus menggunakan diagram. Diagram use case digunakan untuk mengidentifikasi aktor (user atau sistem lain) dan proses-proses yang mereka lakukan.
* Sistem Sequence Diagram: Sistem Sequence Diagram (SSD) adalah gambar yang menunjukkan, untuk skenario tertentu dari sebuah use case, kejadian-kejadian yang menghasilkan aktor-aktor eksternal, pesanan mereka, dan kemungkinan sistem antar-kejadian.
* User interface dokumentasi (jika ada): Dokumen yang menunjukkan dan menggambarkan tampilan dan nuansa dari produk akhir antarmuka pengguna. Hal ini tidak diharuskan untuk memiliki ini, tapi hal itu membantu untuk memvisualisasikan produk akhir dan karena itu membantu perancang.
* Model data relasional (jika ada): Sebuah model data adalah model abstrak yang menggambarkan bagaimana data direpresentasikan dan digunakan. Jika suatu benda database tidak digunakan, model data relasional harus biasanya akan dibuat sebelum desain, karena strategi yang dipilih untuk Pemetaan objek-relasional merupakan keluaran dari proses desain OO. Namun, adalah mungkin untuk mengembangkan model data relasional dan berorientasi objek artefak desain secara paralel, dan pertumbuhan suatu artefak dapat merangsang penyempurnaan artefak lain.

Object-oriented concepts

Kelima konsep dasar desain berorientasi objek adalah tingkat pelaksanaan fitur yang dibangun dalam bahasa pemrograman. Fitur-fitur ini sering disebut dengan nama-nama umum ini:
* Obyek / Kelas: A ketat coupling atau asosiasi struktur data dengan metode atau fungsi-fungsi yang bertindak pada data. Hal ini disebut kelas, atau objek (sebuah objek dibuat berdasarkan kelas). Setiap objek melayani fungsi yang terpisah. Hal ini didefinisikan oleh sifat-sifatnya, apa itu dan apa yang dapat dilakukan. Sebuah objek dapat menjadi bagian dari sebuah kelas, yang merupakan kumpulan objek-objek yang serupa.
* Informasi bersembunyi: Kemampuan untuk melindungi beberapa komponen objek dari entitas eksternal. Hal ini diwujudkan dengan kata kunci bahasa untuk mengaktifkan variabel dinyatakan sebagai pribadi atau dilindungi untuk yang memiliki kelas.
* Inheritance: Kemampuan untuk kelas untuk memperpanjang atau menggantikan fungsi kelas lain. Yang disebut subclass memiliki seluruh bagian yang berasal (diturunkan) dari SUPERCLASS dan kemudian ia memiliki seperangkat fungsi dan data.
* Interface: Kemampuan untuk menunda pelaksanaan sebuah metode. Kemampuan untuk menetapkan fungsi atau metode tanda tangan tanpa mengimplementasikannya.
* Polimorfisme: Kemampuan untuk menggantikan obyek dengan subobjects. Kemampuan suatu objek-variabel mengandung, tidak hanya objek, tetapi juga seluruh subobjects….

Designing concepts

* Mendefinisikan objek, membuat diagram kelas dari konseptual diagram: Biasanya peta entitas ke kelas.
* Mengidentifikasi atribut.
* Gunakan pola desain (jika ada): Sebuah pola desain bukanlah desain selesai, itu adalah deskripsi dari sebuah solusi untuk masalah umum, dalam konteks [1]. Keuntungan utama menggunakan pola desain adalah bahwa hal itu dapat digunakan kembali dalam beberapa aplikasi. Juga dapat dianggap sebagai template untuk bagaimana memecahkan masalah yang dapat digunakan dalam berbagai situasi dan / atau aplikasi. Desain object-oriented biasanya menunjukkan pola-pola hubungan dan interaksi antara kelas-kelas atau objek, tanpa menentukan aplikasi akhir kelas atau objek-objek yang terlibat.
* Tentukan kerangka aplikasi (jika ada): Aplikasi kerangka adalah istilah yang biasanya digunakan untuk merujuk kepada satu set perpustakaan atau kelas yang digunakan untuk mengimplementasikan struktur standar sebuah aplikasi untuk sistem operasi tertentu. Dengan bundling sejumlah besar kode dapat digunakan kembali ke dalam kerangka kerja, banyak waktu yang disimpan untuk pengembang, karena dia adalah tugas disimpan dalam jumlah besar penulisan ulang kode standar untuk setiap aplikasi baru yang dikembangkan.
* Identifikasi obyek gigih / data (jika ada): Identifikasi benda-benda yang harus bertahan lebih lama daripada satu runtime dari aplikasi. Jika sebuah database relasional yang digunakan, desain relasi objek pemetaan.
* Identifikasi dan define remote objek (jika berlaku).

Output (deliverables) of object-oriented design

* Sequence Diagram: Sistem Perluas Sequence Diagram untuk menambahkan objek khusus yang menangani peristiwa sistem.
Sebuah diagram urutan menunjukkan, seperti garis-garis vertikal yang paralel, proses yang berbeda atau benda-benda yang hidup secara bersamaan, dan seperti anak panah horisontal, pesan-pesan yang dipertukarkan antara mereka, dalam urutan yang mereka terjadi.
* Kelas diagram: diagram kelas A adalah jenis struktur statis UML Diagram yang menggambarkan struktur sebuah sistem dengan menunjukkan sistem kelas, atribut mereka, dan hubungan antara kelas-kelas. Pesan dan kelas-kelas yang diidentifikasi melalui pengembangan diagram urutan dapat berfungsi sebagai masukan kepada generasi otomatis kelas global diagram sistem.

Some design principles and strategies

* Dependency injection: Ide dasarnya adalah bahwa jika sebuah objek bergantung pada memiliki sebuah contoh dari beberapa objek lain maka objek yang diperlukan adalah “disuntikkan” ke dalam tergantung objek, misalnya, yang melewati sebuah koneksi database sebagai argumen untuk constructor bukan menciptakan satu internal.
* Acyclic prinsip dependensi: grafik Ketergantungan paket atau komponen seharusnya tidak memiliki siklus. Ini juga disebut sebagai memiliki asiklis diarahkan grafik. [2] Sebagai contoh, paket C tergantung pada paket B, yang tergantung pada paket A. Jika paket A juga tergantung pada paket C, maka Anda akan memiliki siklus.
* Composite prinsip reuse: nikmat polimorfik komposisi benda-benda di atas warisan.

Unified Modeling Language

Unified Modeling Language (UML) adalah standar untuk keperluan umum bahasa pemodelan di bidang rekayasa perangkat lunak. Standar dikelola, dan diciptakan oleh, Objek Management Group.

Gambar UML
UML mencakup seperangkat teknik notasi grafis untuk menciptakan model visual perangkat lunak sistem intensif.

Overview

The Unified Modeling Language (UML) digunakan untuk menentukan, bayangkan, memodifikasi, membangun dan mendokumentasikan artifak dari perangkat lunak berorientasi objek sistem yang intensif dalam pengembangan. UML menawarkan sebuah cara standar untuk memvisualisasikan suatu cetak biru arsitektur sistem, termasuk elemen seperti sebagai:
* Aktor
* Proses bisnis
* (Logis) komponen
* Kegiatan
* Bahasa pemrograman pernyataan
* Database schemas, dan
* Komponen perangkat lunak dapat digunakan kembali.
UML menggabungkan teknik-teknik terbaik dari data model (diagram hubungan entitas), model bisnis (aliran kerja), pemodelan objek, dan komponen model. Hal ini dapat digunakan dengan semua proses, sepanjang siklus hidup pengembangan perangkat lunak, dan teknologi implementasi yang berbeda. UML telah disintesis notasi dari metode Booch, Objek-teknik modeling (OMT) dan Object-oriented software engineering (OOSE ) oleh sekering mereka menjadi satu, umum dan bahasa pemodelan digunakan secara luas. UML bertujuan untuk menjadi standar bahasa pemodelan yang dapat model bersamaan dan sistem terdistribusi. UML secara de facto merupakan standar industri, dan berkembang di bawah naungan Object Management Group (OMG). OMG mulanya disebut untuk informasi tentang metodologi berorientasi objek yang dapat membuat bahasa model perangkat lunak ketat. Banyak pemimpin industri telah merespon dengan sungguh-sungguh untuk membantu menciptakan standar UML. Model UML dapat secara otomatis diubah menjadi representasi lain (mis. Java) dengan cara transformasi QVT-seperti bahasa, yang didukung oleh OMG. UML adalah extensible, menawarkan mekanisme berikut ini untuk kustomisasi: profil dan stereotip. Semantik perluasan oleh profil yang ditingkatkan dengan 2,0 UML revisi besar.

History


Gambar Historis

Before UML 1.x

Setelah Rational Software Corporation disewa James Rumbaugh dari General Electric pada tahun 1994, perusahaan ini menjadi sumber bagi kedua paling populer pemodelan berorientasi obyek pendekatan of the day: Rumbaugh’s OMT, yang lebih baik untuk analisis berorientasi obyek (öÔÄ), dan Grady Booch’s metode Booch, yang lebih baik untuk desain berorientasi objek (OOD). Mereka segera dibantu dalam usaha mereka oleh Ivar Jacobson, pencipta dari object-oriented software engineering (OOSE) method. Rasional Jacobson bergabung pada tahun 1995, setelah perusahaannya, Objectory AB, diakuisisi oleh Rasional. Ketiga methodologists secara kolektif disebut sebagai Tiga Amigos, karena mereka dikenal sering berdebat satu sama lain mengenai praktek-praktek metodologis. Rasional Pada tahun 1996 menyimpulkan bahwa kelimpahan adalah bahasa pemodelan yang memperlambat adopsi teknologi obyek, sehingga reposisi yang bekerja pada metode yang bersatu, mereka bertugas Three Amigos dengan pengembangan non-proprietary Unified Modeling Language. Perwakilan dari perusahaan teknologi objek bersaing dikonsultasikan selama OOPSLA ’96; mereka memilih kotak untuk mewakili kelas atas Grady Booch’s Booch metode notasi yang menggunakan simbol awan. Di bawah kepemimpinan teknis Three Amigos, sebuah konsorsium internasional yang disebut Mitra UML diselenggarakan pada tahun 1996 untuk menyelesaikan Unified Modeling Language (UML) spesifikasi, dan mengusulkan sebagai respons terhadap RFP OMG. The UML Partners ’1,0 spesifikasi UML rancangan diusulkan kepada OMG pada Januari 1997. Selama bulan yang sama Mitra UML membentuk Gugus Tugas Semantik, yang dipimpin oleh Cris Kobryn dan dikelola oleh Ed Eykholt, untuk menyelesaikan semantik spesifikasi dan mengintegrasikannya dengan upaya standarisasi lainnya. Hasil pekerjaan ini, UML 1.1, telah disampaikan kepada OMG pada bulan Agustus 1997 dan diadopsi oleh OMG pada November 1997.

UML 1.x

Sebagai model notasi, pengaruh dari notasi OMT mendominasi (misalnya, dengan menggunakan persegi panjang untuk kelas dan objek). Meskipun Booch “awan” notasi itu turun, Booch kemampuan untuk menentukan tingkat yang lebih rendah detail desain dipeluk. Kasus penggunaan notasi dari komponen Objectory dan notasi dari Booch yang terintegrasi dengan seluruh notasi, tetapi integrasi semantik relatif lemah dalam UML 1.1, dan tidak benar-benar tetap sampai 2,0 UML revisi besar.
Konsep-konsep dari metode OO lainnya juga longgar terintegrasi dengan UML dengan maksud bahwa UML akan mendukung semua metode OO. Banyak orang lain yang juga berkontribusi, dengan pendekatan model flavoring banyak hari, termasuk: Tony Wasserman dan Peter Pircher dengan “Structured Berorientasi Objek Desain (OOSD)” notasi (bukan metode), Ray Buhr’s “Sistem Desain dengan Ada” , Archie Bowen penggunaan dan waktu analisis kasus, Paul Ward analisis data dan David Harel’s “Statecharts”; sebagai kelompok berusaha untuk memastikan cakupan luas dalam real-time sistem domain. Akibatnya, UML ini berguna dalam berbagai permasalahan dan rekayasa, dari proses tunggal, aplikasi untuk pengguna tunggal bersamaan, sistem terdistribusi, membuat UML kaya tapi juga besar.
Development toward UML 2.0
UML telah berkembang secara signifikan sejak UML 1.1. Beberapa revisi kecil (UML 1.3, 1.4, dan 1,5) tetap kekurangan dan bug dengan UML versi pertama, diikuti oleh 2,0 UML revisi besar yang diadopsi oleh OMG tahun 2005.
Ada empat bagian ke 2.x UML spesifikasi:
  1. superstruktur yang mendefinisikan notasi dan semantik untuk diagram dan elemen model mereka;
  2. Infrastruktur yang mendefinisikan metamodel inti yang didasarkan atas kapal;
  3. Objek Constraint Language (OCL) untuk mendefinisikan aturan untuk model elemen;
  4. dan UML Diagram Interchange yang mendefinisikan bagaimana tata letak diagram UML 2 dipertukarkan.
Versi terbaru ini mengikuti standar: superstruktur UML versi 2.2, Infrastruktur UML versi 2.2, OCL versi 2.0, dan UML Diagram Interchange versi 1.0. Meskipun banyak alat UML dukungan beberapa fitur baru dari UML 2.x, yang OMG tidak memberikan tes objektif suite untuk menguji kepatuhan dengan spesifikasi.

Unified Modeling Language topics

Software Development Methods

UML bukanlah metode pembangunan itu sendiri, [8] Namun, ia dirancang agar kompatibel dengan terkemuka berorientasi obyek metode pengembangan perangkat lunak dari waktu (misalnya OMT, metode Booch, Objectory). Sejak UML telah berevolusi, beberapa metode ini telah menyusun kembali untuk mengambil keuntungan dari notasi baru (misalnya OMT), dan metode-metode baru telah diciptakan berdasarkan UML. Yang paling terkenal adalah IBM Rational Unified Process (RUP). Ada banyak metode berbasis UML seperti Abstraksi Metode, Metode Pengembangan Sistem Dinamis, dan lain-lain, yang dirancang untuk menyediakan solusi yang lebih spesifik, atau mencapai tujuan yang berbeda.

Modeling

Hal ini sangat penting untuk membedakan antara model UML dan himpunan diagram dari sebuah sistem. Diagram adalah sebagian representasi grafis dari suatu sistem model. Model ini juga berisi “semantik backplane” – dokumentasi seperti ditulis menggunakan kasus-kasus yang mendorong elemen-elemen model dan diagram.
UML diagram mewakili dua pandangan yang berbeda dari sebuah sistem model [9]:
* Statis (atau struktural) melihat: Menekankan struktur statis dari sistem menggunakan object, atribut, operasi dan hubungan. View struktural kelas termasuk diagram dan diagram struktur komposit.
* Dynamic (atau perilaku) melihat: Menekankan perilaku dinamis sistem dengan menunjukkan kolaborasi antara benda dan perubahan keadaan internal objek. Pandangan ini termasuk urutan diagram, diagram aktivitas dan diagram mesin negara. UML model dapat dipertukarkan antara alat UML dengan menggunakan format pertukaran XMI.

Diagrams overview

UML 2,2 memiliki 14 jenis diagram terbagi menjadi dua kategori. [10] Tujuh Diagram struktural mewakili jenis informasi, dan yang lainnya mewakili tujuh jenis perilaku umum, termasuk empat yang mewakili berbagai aspek interaksi. Diagram ini dapat dikategorikan secara hirarkis seperti ditunjukkan pada diagram kelas berikut:

Gambar Diagram Struktural
UML UML tidak membatasi jenis elemen untuk tipe diagram tertentu. Secara umum, setiap elemen UML mungkin muncul di hampir semua jenis diagram; fleksibilitas ini sebagian telah dibatasi dalam UML 2.0. UML profil dapat menentukan jenis diagram tambahan atau memperpanjang diagram yang ada dengan notasi tambahan. Sesuai dengan tradisi rekayasa gambar, komentar atau catatan penjelasan penggunaan, kendala, atau niat yang diperbolehkan dalam sebuah diagram UML.

Structure diagrams

Diagram Struktur menekankan hal-hal apa yang harus dalam sistem yang dimodelkan:
* Kelas diagram: diagram kelas menggambarkan struktur sebuah sistem dengan menunjukkan sistem kelas, atribut mereka, dan hubungan di antara kelas.
* Component diagram: menggambarkan bagaimana sebuah sistem perangkat lunak dibagi menjadi komponen dan menunjukkan ketergantungan antara komponen-komponen ini.
* Composite struktur diagram: menggambarkan struktur internal dari suatu kelas dan kolaborasi yang memungkinkan struktur ini.
* Deployment diagram: berfungsi untuk model perangkat keras sistem yang digunakan dalam implementasi, dan pelaksanaan lingkungan dan artefak digunakan pada perangkat keras.
* Objek diagram menunjukkan lengkap atau sebagian tampilan struktur sebuah sistem model pada waktu tertentu.
* Paket diagram: menggambarkan bagaimana sistem terbagi menjadi kelompok logis dengan menunjukkan dependensi di antara pengelompokan tersebut.
* Profil diagram: beroperasi pada tingkat metamodel untuk menunjukkan stereotip sebagai kelas dengan <> stereotip, dan profil sebagai paket dengan <> stereotipe. Perpanjangan hubungan (garis solid dengan tertutup, penuh mata panah) menunjukkan apa elemen metamodel stereotip tertentu memperpanjang.
Class diagram

Gambar Class Diagram
Component diagram

Gambar Diagram Komponen
Composite structure diagrams

Gambar Diagram Struktur
Deployment diagram

Gambar Diagram Deployment
Object diagram

Gambar Diagram Objek
Package diagram

Gambar Diagram Pakage

Behavior diagrams

Diagram perilaku menekankan apa yang harus terjadi dalam sistem yang dimodelkan:
* Activity diagram merepresentasikan bisnis dan operasional langkah-demi-langkah alur kerja komponen dalam sebuah sistem. Diagram aktivitas keseluruhan menunjukkan aliran kontrol.
* Negara mesin diagram: notasi standar untuk menjelaskan banyak sistem, dari program-program komputer untuk proses bisnis.
* Gunakan diagram kasus: menunjukkan fungsionalitas yang disediakan oleh sistem dari segi aktor, tujuan mereka digambarkan sebagai kasus penggunaan, dan setiap ketergantungan di antara mereka yang menggunakan kasus.
UML Activity Diagram
State Machine diagram

Gambar State Machine Diagram
Use case diagram

Gambar Use Case Diagram

Interaction diagrams

Interaksi diagram, perilaku subset dari diagram, menekankan aliran kontrol dan data di antara hal-hal dalam sistem yang dimodelkan:
* Komunikasi diagram: menunjukkan interaksi antara obyek atau bagian dalam hal sequencing pesan. Mereka mewakili suatu kombinasi dari informasi yang diambil dari Class, Sequence, dan Use Case Diagram yang menggambarkan struktur statis baik dan perilaku dinamis suatu sistem.
* Interaksi overview diagram adalah diagram jenis kegiatan yang mewakili simpul diagram interaksi.
* Sequence diagram memperlihatkan bagaimana objek berkomunikasi satu sama lain dalam suatu urutan pesan. Juga menunjukkan benda lifespans relatif terhadap pesan-pesan tersebut.
* Timing diagram: adalah tipe khusus diagram interaksi, di mana fokusnya adalah pada kendala waktu.
Communication diagram

Gambar Diagram Komunikasi
Interaction overview diagram

Gambar Diagram Interaktive
Sequence diagram

Gambar Squence Diagram

Meta modeling

Objek Management Group (OMG) telah mengembangkan sebuah arsitektur metamodeling untuk menentukan Unified Modeling Language (UML), yang disebut Meta-Object Facility (MOF). The Meta-Object Facility standar untuk model-driven engineering, dirancang sebagai arsitektur berlapis empat, seperti ditunjukkan pada gambar di sebelah kanan. Menyediakan meta meta-model di lapisan atas, yang disebut lapisan M3. M3-model ini adalah bahasa yang digunakan oleh Meta-Object Facility untuk membangun metamodels, yang disebut M2-model. Contoh yang paling menonjol dari layer 2 Meta-Objek adalah model Fasilitas metamodel UML, model yang menggambarkan UML itu sendiri. M2-model ini menggambarkan unsur-unsur dari M1-lapisan, dan dengan demikian M1-model. Ini akan, misalnya, model ditulis dalam UML. Lapisan terakhir adalah M0-layer atau lapisan data. Hal ini digunakan untuk menggambarkan objek dunia nyata.
Luar M3-model, Meta-Object Facility menjelaskan cara untuk membuat dan memanipulasi model dan metamodels oleh CORBA mendefinisikan interface yang menggambarkan operasi tersebut. Karena kesamaan antara Meta-Object Facility M3-model dan struktur UML model, Meta-Obyek Sarana metamodels biasanya dimodelkan sebagai kelas UML diagram. Sebuah standar mendukung Meta-Object Facility XMI, yang mendefinisikan XML pertukaran berbasis format untuk model di-M3, M2-, atau M1-Layer.

Illustration of the Meta-Object Facility.

Gambar Ilustrasi Fasilitas Meta-Object

Criticisms

Meskipun UML adalah diakui dan digunakan secara luas model standar, ini sering dikritik karena berikut:
Standar mengasapi Bertrand Meyer, dalam bingkai esai satir sebagai siswa permintaan perubahan nilai, tampaknya dikritik UML sebagai tahun 1997 karena tidak terkait dengan perangkat lunak berorientasi obyek pembangunan; yang disclaimer ini ditambahkan kemudian menunjukkan bahwa perusahaan-nya tetap mendukung UML. Ivar Jacobson, seorang co-arsitek UML, mengatakan bahwa keberatan terhadap UML 2,0 ‘s ukuran yang cukup valid untuk mempertimbangkan penerapan agen cerdas untuk masalahini berisi banyak diagram dan konstruksi yang berlebihan atau jarang digunakan. Permasalahan dalam belajar dan mengadopsi
Masalah dikutip dalam bagian ini membuat belajar dan mengadopsi UML problematis, terutama ketika diperlukan para insinyur tidak memiliki keterampilan prasyarat. Dalam prakteknya, orang sering menggambar diagram dengan simbol-simbol yang disediakan oleh alat KASUS mereka, tetapi tanpa makna simbol yang dimaksudkan menyediakan. Linguistik ketidaklogisan. Tulisan yang sangat miskin dari standar UML sendiri – diasumsikan menjadi akibat dari yang telah ditulis oleh seorang non-native speaker inggris – serius mengurangi nilai normatif mereka. Dalam hal ini standar-standar yang telah dikutip secara luas, dan memang pilloried, sebagai contoh utama geekspeak dimengerti. Kemampuan bahasa UML dan ketidaksesuaian pelaksanaan. Seperti halnya sistem notasi, UML dapat mewakili beberapa sistem lebih ringkas atau efisien daripada yang lain. Jadi seorang pengembang gravitates terhadap solusi yang berada di persimpangan kemampuan pelaksanaan UML dan bahasa. Masalah ini terutama diucapkan jika bahasa pelaksanaan tidak mematuhi ortodoks doktrin berorientasi objek, seperti persimpangan diatur antara pelaksanaan UML dan mungkin bahasa yang jauh lebih kecil. Berfungsi interchange format. Sementara XMI (XML Metadata Interchange) standar yang dirancang untuk memfasilitasi pertukaran model UML, telah sebagian besar tidak efektif dalam pertukaran praktis 2.x UML model. Interoperabilitas ketidakefektifan ini disebabkan oleh dua alasan. Pertama, XMI 2.x besar dan kompleks di dalam dirinya sendiri, karena itu dimaksudkan untuk mengatasi masalah teknis lebih ambisius daripada bertukar 2.x UML model. Secara khusus, ia mencoba untuk menyediakan sebuah mekanisme untuk memfasilitasi pertukaran bahasa model apapun lainnya didefinisikan oleh OMG’s Meta-Object Facility (MOF). Kedua, UML Diagram Interchange 2.x spesifikasi kurang memadai untuk memfasilitasi pertukaran diandalkan notasi UML 2.x antara alat pemodelan. Sejak UML adalah bahasa pemodelan visual, kekurangan ini adalah penting bagi modelers yang tidak ingin redraw diagram mereka.
Modeling ahli telah menulis kritik tajam dari UML, termasuk Bertrand Meyer’s “UML: Positif Spin”, [11] dan Brian Henderson-Sellers dan Cesar Gonzalez-Perez dalam “Penggunaan dan Penyalahgunaan dari stereotip Mekanisme dalam UML 1.x dan 2.0″ .
Simpulan
Model data adalah metode yang digunakan untuk menentukan dan menganalisis data persyaratan yang dibutuhkan untuk mendukung proses bisnis dari sebuah organisasi.Persyaratan data yang dicatat sebagai model data konseptual dengan data terkait definisi.Sebenarnya pelaksanaan model konseptual yang disebut model data logis. Untuk menerapkan salah satu model data konseptual mungkin memerlukan beberapa model data logis. Pemodelan data tidak hanya mendefinisikan elemen data, tetapi struktur dan hubungan di antara mereka. Data model teknik dan metodologi yang digunakan untuk model data dalam standar, konsisten, dapat diprediksi cara untuk mengelolanya sebagai sumber daya. Penggunaan standar pemodelan data sangat disarankan untuk semua proyek yang membutuhkan standar sarana untuk mendefinisikan dan menganalisis data dalam sebuah organisasi, misalnya data menggunakan model: untuk mengelola data sebagai sumber daya; untuk integrasi sistem informasi; untuk merancang database / data gudang (repositori data alias) .
Pemodelan data dapat dilakukan pada berbagai jenis proyek dan dalam berbagai fase proyek.Model data bersifat progresif, tidak ada yang namanya data akhir model untuk bisnis atau aplikasi. Sebaliknya model data harus dianggap sebagai dokumen hidup yang akan berubah sebagai respons terhadap perubahan bisnis. Model data idealnya harus disimpan dalam repositori sehingga mereka dapat diambil, dikembangkan, dan diedit dari waktu ke waktu.Whitten (2004) ditetapkan dua jenis data model:
Pemodelan data strategis: Ini adalah bagian dari penciptaan sistem informasi strategi, yang mendefinisikan visi dan keseluruhan sistem informasi arsitektur untuk didefinisikan. Informasi teknik adalah suatu metodologi yang mencakup pendekatan ini.
Model data selama analisis sistem: Dalam analisis sistem model data logika diciptakan sebagai bagian dari pengembangan database baru.
Model data juga merupakan teknik untuk membuat rincian kebutuhan bisnis untuk database.Hal ini kadang-kadang disebut database model karena model data pada akhirnya diterapkan dalam database.
The Unified Modeling Language (UML) digunakan untuk menentukan, bayangkan, memodifikasi, membangun dan mendokumentasikan artifak dari perangkat lunak berorientasi objek sistem yang intensif dalam pengembangan. UML menawarkan sebuah cara standar untuk memvisualisasikan suatu cetak biru arsitektur sistem, termasuk elemen seperti sebagai:
* Aktor
* Proses bisnis
* (Logis) komponen
* Kegiatan
* Bahasa pemrograman pernyataan
* Database schemas, dan
* Komponen perangkat lunak dapat digunakan kembali.
UML menggabungkan teknik-teknik terbaik dari data model (diagram hubungan entitas), model bisnis (aliran kerja), pemodelan objek, dan komponen model. Hal ini dapat digunakan dengan semua proses, sepanjang siklus hidup pengembangan perangkat lunak, dan teknologi implementasi yang berbeda. UML telah disintesis notasi dari metode Booch, Objek-teknik modeling (OMT) dan Object-oriented software engineering (OOSE ) oleh sekering mereka menjadi satu, umum dan bahasa pemodelan digunakan secara luas. UML bertujuan untuk menjadi standar bahasa pemodelan yang dapat model bersamaan dan sistem terdistribusi. UML secara de facto merupakan standar industri, dan berkembang di bawah naungan Object Management Group (OMG). OMG mulanya disebut untuk informasi tentang metodologi berorientasi objek yang dapat membuat bahasa model perangkat lunak ketat. Banyak pemimpin industri telah merespon dengan sungguh-sungguh untuk membantu menciptakan standar UML.
Model UML dapat secara otomatis diubah menjadi representasi lain (mis. Java) dengan cara transformasi QVT-seperti bahasa, yang didukung oleh OMG. UML adalah extensible, menawarkan mekanisme berikut ini untuk kustomisasi: profil dan stereotip. Semantik perluasan oleh profil yang ditingkatkan dengan 2,0 UML revisi besar.

No comments :

Post a Comment

Kebahagiaan sejati bukanlah pada saat kita berhasil meraih apa yg kita perjuangkan, melainkan bagaimana kesuksesan kita itu memberi arti atau membahagiakan orang lain.

Follower

Google+ Followers

Translator

English French German Japanese Korean Chinese Russian Spanish
India Saudi Arabia Netherland Portugal Italian Philippines Ukraina Norwegia
Powered by
Widget translator