Gambar dari www.uml.org
Artikel ini dikhususkan untuk UML dan kekhasan penerapannya pada saat ini. Sedikit informasi historis, sangat sedikit, hanya poin utama:
- UML lahir di tahun 90-an sebagai hasil dari kerja untuk menciptakan bahasa pemodelan berorientasi objek.
- Spesifikasi 1.0 keluar pada 1997.
- Spesifikasi 2.0 keluar pada 2005.
- Hingga saat ini, UML 2.5 telah mengembangkan beberapa profil seperti SysML dan SoaML .
Jika Anda melihat bagaimana UML diterapkan dulu dan sekarang, dan pikirkan, Anda dapat menarik kesimpulan berikut: Biarkan versi UML sekarang 2.5, tetapi prinsip-prinsip penggunaan bahasa belum berubah sejak versi pertama.
Dan sebagai konsekuensinya: Analis menggunakan konsep menggambarkan sistem perangkat lunak, yang ditetapkan lebih dari 20 tahun yang lalu. Konsepnya sendiri bagus, tetapi Anda perlu menghubungkannya dengan tempat dan konteks penggunaan.
Jika kami melanjutkan analisis aplikasi UML ini, dan juga menghubungkannya dengan persyaratan saat ini, maka kesimpulannya adalah sebagai berikut:
- Semua teknik untuk menggunakan UML "berkeliling" Gunakan Case Driven Development.
- Model UML tidak memiliki integritas. Pendekatan yang dipilih dari deskripsi terpisah dari aspek struktur dan perilaku, tingkat bisnis dan aplikasi mempersulit persepsi model secara keseluruhan.
- UML adalah bahasa berorientasi objek, yang membuatnya sulit untuk mengekspresikan konsep lain dengannya.
Saya tidak akan mengatakan apa-apa tentang pendekatan Pengembangan Case Driven Development, salah satu inkarnasinya adalah Proses Bersatu Rasional. Selanjutnya, saya akan berbicara tentang dua poin terakhir.
Aspek presentasi
UML terdiri dari banyak diagram. Masing-masing mematuhi aturannya sendiri, menggunakan elemen dan panah dalam pemahamannya sendiri. Dan dari luar tidak terlihat seperti bahasa yang disatukan, tetapi sebagai seperangkat representasi yang berbeda, yang sering disajikan sebagai kesempatan untuk melihat area subjek dari sudut pandang yang berbeda. Dengan keberhasilan yang sama, pisau Swiss dapat disebut alat terpadu, yang pada dasarnya adalah satu set yang terdiri dari pisau, obeng, pembuka botol, sendok, garpu, dan semua ini pada satu pegangan.
Apa yang dilakukan seorang analis ketika mencoba menghubungkan semua grafik ke dalam satu model? Dia mulai membangun bagan hybrid dan tabel tautan. Hasilnya bukan model tunggal, tetapi banyak grafik, yang ditambahkan grafik dan tabel.
Tingkat presentasi
Misalkan analis bisnis mendeskripsikan area subjek menggunakan diagram UML. Dan sekarang seorang analis sistem atau analis yang sama perlu membentuk model sistem perangkat lunak. Jika analis berfokus pada UML, maka ia akan mulai membuat tampilan yang sesuai dengan yang dibuat sebelumnya, tetapi sudah dalam kerangka sistem. Ini akan terlihat seperti diagram yang sama lagi.
Dan apa yang akan dilakukan analis ketika dia ingin membandingkan deskripsi area subjek dan model sistem?
Dia lagi mulai membangun diagram hibrida, tabel tautan, dan penelusuran.
Hasilnya lagi banyak grafik dan tabel.
Masih perlu dicatat bahwa UML adalah bahasa lama dan ada banyak buku dan contoh lama untuk itu.Yang terutama menggambarkan kasus-kasus transisi dari bisnis non-otomatis ke bisnis otomatis. Dan analis belajar dari contoh-contoh ini. Namun saat ini teknologi informasi telah merambah ke mana-mana. Pendekatan bisnis-per-bisnis, IT-apart tidak dapat diterima .
Pendekatan Berorientasi Layanan
UML adalah bahasa berorientasi objek, yang membuatnya sulit untuk mengekspresikan konsep lain dengannya. Misalnya berorientasi layanan. Dalam profil UML standar tidak ada konsep "Layanan", tetapi ada profil SoaML , yang disajikan sebagai bahasa pemodelan untuk arsitektur berorientasi layanan.
Saya akan berbicara singkat tentang pendekatan berorientasi layanan, sehingga nanti jelas mengapa SoaML tidak cocok untuk pemodelannya. Berdasarkan interpretasi definisi dari TOGAF .
Untuk formalisasi sederhana dari pendekatan berorientasi layanan, kita perlu 2 abstraksi:
- Suatu proses adalah aliran kontrol antara / lebih dari layanan. Harus juga dikatakan bahwa proses tersebut adalah urutan tindakan yang bersama-sama mencapai hasil tertentu.
- Layanan adalah elemen perilaku yang menyediakan fungsionalitas tertentu sebagai respons terhadap permintaan dari subjek atau layanan lain. Layanan menyediakan atau mendukung kemampuan , memiliki antarmuka yang ditentukan secara eksplisit, dan dikendalikan secara eksplisit.
Mari kita lihat bagaimana ini dimodelkan dalam SoaML. Pada saat yang sama, mari kita bandingkan bagaimana pemodelan berorientasi objek di UML dan pemodelan berorientasi layanan di SoaML akan berbeda.
Man and Shop
Tujuan: Menjelaskan model pembelian barang di toko.
Pendekatan berorientasi objek, saya pikir, jelas dan sederhana untuk semua orang. Agar tidak membuang waktu, kami tidak akan mempertimbangkan lapisan bisnis. Saya pikir semua orang bisa membayangkan di kepala mereka Kasus Penggunaan yang menasihati dan perinciannya dalam bentuk diagram aktivitas atau diagram urutan.
Seseorang bertindak bukan sebagai pengguna, tetapi sebagai salah satu pihak dalam interaksi.
Sekarang mari kita selesaikan masalah ini menggunakan SoaML, secara ketat sesuai dengan spesifikasi .
Dalam diagram ini, kami mendefinisikan komunitas yang berinteraksi, ini adalah Store dan Person.
Kami menentukan proses bisnis "Menjual barang" di antara mereka, di mana Toko bertindak sebagai "penjual", dan Orang sebagai "pembeli".
Berdasarkan proses bisnis, kami sekarang dapat mengidentifikasi layanan bisnis berikutnya, di SoaML, classifier ServiceContract digunakan untuk ini.
Dalam kerangka layanan ini: Penjual bertindak sebagai penyedia, dan Pembeli sebagai konsumen.
Penjual sebagai pemasok menyediakan satu operasi "jual". Analisis bisnis sudah berakhir, kita pergi ke tingkat sistem.
Kita perlu mensimulasikan pada tingkat sistem versi terbaru dari proses bisnis kita untuk menjual barang. Untuk ini, saya memilih diagram urutan, Anda dapat menggunakan diagram perilaku lainnya.
Dari proses bisnis yang diperbarui, kami dapat memilih satu operasi "menjual", kami akan mengaturnya menjadi antarmuka dasar "Siapa yang tahu cara menjual".
Selanjutnya, kita perlu menggambarkan antarmuka layanan yang akan digunakan untuk mengimplementasikan layanan.
Kami mendapatkan antarmuka layanan berikut:
- "Keinginan untuk menjual", yang diwarisi dari antarmuka "Jual";
- "Perlu membeli", yang tergantung pada antarmuka "dapat menjual."
Anda sekarang dapat mewakili model layanan target sebagai diagram struktur komposit.
Mari kita bandingkan hasil pemodelan berorientasi objek di UML dan pemodelan berorientasi layanan di SoaML.
Secara visual, seluruh perbedaannya adalah dalam kotak kecil di perbatasan komponen. Saya menandai mereka dalam warna merah. Apakah itu bedanya?
Perbedaan antara pemodelan berorientasi objek dan berorientasi layanan sebenarnya ada, hanya SoaML telah mengurangi segalanya menjadi objek. Tetapi lebih lanjut tentang itu nanti.
Dan sekarang mari kita selesaikan pertimbangan SoaML dalam kasus yang lebih kompleks, maka kita akan mendapatkan tentang skema berikut.
Apa yang salah, menurut saya, dengan SoaML.
pertama: Sekali lagi, masalah dengan integritas bahasa dan hubungan antara tingkat bisnis dan tingkat aplikasi, Anda sendiri melihat betapa sulitnya segala sesuatu berhubungan satu sama lain.
Kedua : Layanan digambarkan sebagai objek struktur, ini tidak baik. Dalam pidato Rusia, frasa "Penyedia mewakili layanan" adalah umum, ini adalah pendekatan berorientasi komponen yang diimplementasikan dalam SoaML. Tetapi dalam kasus paradigma berorientasi layanan, lebih tepat mengatakan "Pemasok menyediakan layanan." Dan jika Anda menerjemahkan "Layanan" ke dalam bahasa Rusia secara berbeda, maka semuanya langsung jatuh pada tempatnya: "Pemasok menyediakan layanan ." Dari sudut pandang ini, "Layanan" bukan "Objek", itu adalah "Perilaku".
Ketiga: Pada slide tentang arsitektur berorientasi layanan, saya berbicara tentang dua abstraksi: Proses dan Layanan. Melihat dan mendeskripsikannya melalui lensa dari pendekatan berorientasi objek, secara sederhana, adalah tugas yang membuat stres.
Paradigma
Ayo kembali ke UML. UML mencoba menggambarkan paradigma lain melalui paradigma.
Dan jika semuanya berjalan dengan paradigma berorientasi komponen, itu dapat direpresentasikan sebagai kelanjutan logis dari yang berorientasi objek. Itu dengan berorientasi pada layanan ternyata buruk.
Dalam hal ini, mengekspresikan satu paradigma melalui ide malang lainnya.
Saya mendemonstrasikan penggunaan konsep seperti itu dengan SoaML menggunakan contoh masalah "Person and Store".
Berlaku untuk paradigma yang lebih baik seperti yang ditunjukkan di bawah ini.
Saya akan menunjukkan bagaimana pemodelan berorientasi layanan berbeda dari berorientasi objek.
Manusia dan Anjing
Tujuan: Menjelaskan model interaksi - Seseorang berjalan dengan Anjing.
Tanpa berpikir dua kali, tugas ini mungkin akan diselesaikan oleh mahasiswa fakultas teknik mana pun. Di sekolah dan universitas dalam spesialisasi yang relevan, pemrograman berorientasi objek adalah wajib. Pendekatan berorientasi objek disajikan di bawah ini.
Dan seperti apa model dengan pendekatan berorientasi layanan? Saya tidak tahu apakah siswa akan menjawab pertanyaan seperti itu.
Inilah yang ingin saya terima. (Pikirkan sebentar untuk dirimu sendiri, lalu lihat)
, . - . () () «».
, . - . () () «».
Anda dapat mengingat sejarah pemrograman berorientasi objek. Betapa skeptis bahkan orang-orang yang sangat otoritatif seperti Edsger Dijkstra dan Niklaus Wirth di awal penampilannya. Dan tetap saja, beberapa orang menganggap OOP tidak layak mendapat perhatian.
Nah, model ini juga bisa menimbulkan senyum. Intinya adalah bahwa paradigma yang berorientasi layanan tidak memiliki dukungan yang memadai di tingkat awal pemrograman dan desain. Untuk programmer, dukungan hanya disediakan oleh kerangka kerja seperti Java Enterprise Edition atau Spring. Saya pikir bahwa programmer mendapatkan mereka dengan kepala yang sudah diformat untuk pendekatan berorientasi objek.
Analis mendasarkan pemahaman mereka tentang arsitektur dan desain berorientasi layanan pada artikel di Internet yang memahami secara berbeda apa itu, dan beberapa artikel tanpa menyelam jauh ke dalam spesifikasi dan rincian teknis umumnya tidak jelas. Akibatnya, analis kembali ke Use Cases yang diterima secara umum antara sistem dan pengguna. Juga umum bahwa arsitektur sistem dan komposisi komponennya sudah diperbaiki oleh arsitek atau ditentukan oleh platform yang dipilih. Dan kemudian analis lagi hanya menggambarkan Use Case antara sistem dan pengguna.
Bandingkan pendekatan berorientasi objek dan pendekatan yang tampaknya konyol ini, di mana si Pria memberikan layanan "Jalan" untuk Anjing. Ketika itu berhenti menjadi konyol bagi Anda, dan pendekatan berorientasi objek tampaknya konyol, di mana Orang mengimplementasikan metode "berjalan",di pintu masuk yang dilayani Anjing !!! Saat itulah Anda memahami paradigma berorientasi layanan.
Perlu dicatat bahwa paradigma ini cukup kompatibel. Seseorang masih dapat melakukan tindakannya yang biasa: tidur dan menari, dan Anjing dapat menggonggong.
Satu hal lagi: Dalam contoh ini, saya memperkenalkan konsep baru "Layanan". Namun, saya belum secara jelas mendefinisikan aturan untuk penggunaannya, tetapi berbeda dari yang ada di SoaML. Di sini Anda perlu berhati-hati, Anda tidak boleh terlalu terbawa dengan ini, karena ekstensi tersebut terkait dengan metamodeling. Mungkin saja terjadi bahwa model yang dibuat ternyata kontradiktif dan tidak jelas.
Alih-alih sebuah kesimpulan
- UML . , . .
- . , . .
- UML . , . , UML, .