Memetakan antara 4 + 1 model tampilan arsitektur & UML

Saya agak bingung tentang bagaimana model tampilan arsitektur 4 +1 memetakan ke UML.

Wikipedia memberikan pemetaan berikut:

• Tampilan logis: Diagram kelas, Diagram komunikasi, Diagram urutan.
• Tampilan pengembangan: Diagram komponen, Diagram paket
• Tampilan proses: Diagram aktivitas
• Tampilan fisik: Diagram penempatan
• Skenario: Diagram use-case

Makalah Peran UML Sequence Diagram Constructs dalam Object Lifecycle Concept memberikan pemetaan berikut:

• Tampilan logis (diagram kelas (CD), diagram objek (OD), diagram urutan (SD), diagram kolaborasi (COD), diagram diagram keadaan (SCD), diagram aktivitas (AD))
• Tampilan pengembangan (diagram paket, diagram komponen),
• Tampilan proses (gunakan diagram kasus, CD, OD, SD, COD, SCD, AD),
• Tampilan fisik (diagram penempatan), dan
• Gunakan tampilan kasus (use case diagram, OD, SD, COD, SCD, AD) yang menggabungkan keempat hal tersebut di atas.

Halaman web UML 4 + 1 Lihat Bahan menyajikan pemetaan berikut:

Akhirnya, buku putih Menerapkan Arsitektur Tampilan 4 + 1 dengan UML 2 memberikan pemetaan lain:

• Tampilan logisDiagram kelas, diagram objek, diagram keadaan, dan struktur komposit
• Tampilan prosesDiagram urutan , diagram komunikasi, diagram aktivitas, diagram waktu, diagram ikhtisar interaksi
• Pandangan pengembanganDiagram komponen
• Pandangan fisikDiagram penyebaran
• Gunakan tampilan kasus kasus, gunakan diagram kasus, diagram aktivitas

Saya yakin pencarian lebih lanjut akan mengungkapkan pemetaan lain juga.

Sementara berbagai orang biasanya memiliki perspektif yang berbeda, saya tidak melihat mengapa ini terjadi di sini. Khususnya, setiap diagram UML menggambarkan sistem dari aspek tertentu. Jadi, misalnya, mengapa "diagram urutan" dianggap menggambarkan "pandangan logis" sistem oleh satu penulis, sedangkan penulis lain menganggapnya sebagai menggambarkan "tampilan proses"?

Bisakah Anda membantu saya mengklarifikasi kebingungan ini?

Meskipun saya umumnya setuju dengan jawaban Bart van Ingen Schenau , saya pikir beberapa poin perlu penjabaran tambahan.

Keuntungan dari Model Tampilan 4 +1 adalah bahwa ia memetakan pemangku kepentingan untuk jenis informasi yang mereka butuhkan, tanpa memerlukan notasi pemodelan khusus untuk digunakan. Penekanannya adalah memastikan bahwa semua kelompok memiliki informasi untuk memahami sistem dan terus melakukan pekerjaan mereka.

4 + 1 Lihat Model Arsitektur Perangkat Lunak dijelaskan dalam makalah Philippe Kruchten's Arsitektur Cetak Biru - The "4 +1" Lihat Model Arsitektur Perangkat Lunak yang awalnya diterbitkan dalam Perangkat Lunak IEEE (November 1995). Publikasi ini tidak membuat referensi khusus ke UML. Bahkan, makalah ini menggunakan notasi Booch untuk tampilan logis, ekstensi ke notasi Booch untuk tampilan proses dan tampilan pengembangan, menyerukan penggunaan "beberapa bentuk" untuk mengembangkan tampilan fisik, dan notasi baru untuk skenario.

Alih-alih mencoba memetakan setiap tampilan ke jenis diagram tertentu, pertimbangkan siapa target audiens dari setiap tampilan dan informasi apa yang mereka butuhkan. Mengetahui hal itu, lihat berbagai jenis model dan model mana yang memberikan informasi yang diperlukan.

Pandangan logis dirancang untuk mengatasi kekhawatiran pengguna akhir tentang memastikan bahwa semua fungsionalitas yang diinginkan ditangkap oleh sistem. Dalam sistem berorientasi objek, ini sering di tingkat kelas. Dalam sistem yang kompleks, Anda mungkin memerlukan tampilan paket dan menguraikan paket menjadi beberapa diagram kelas. Dalam paradigma lain, Anda mungkin tertarik untuk mewakili modul dan fungsi yang disediakannya. Hasil akhirnya harus berupa pemetaan fungsionalitas yang diperlukan untuk komponen yang menyediakan fungsionalitas itu.

Tampilan proses dirancang untuk orang yang mendesain seluruh sistem dan kemudian mengintegrasikan subsistem atau sistem ke dalam sistem sistem. Pandangan ini menunjukkan tugas dan proses yang dimiliki sistem, antarmuka ke dunia luar dan / atau antara komponen dalam sistem, pesan yang dikirim dan diterima, dan bagaimana kinerja, ketersediaan, toleransi kesalahan, dan integritas ditangani.

Pandangan pengembangan terutama untuk pengembang yang akan membangun modul dan subsistem. Ini harus menunjukkan dependensi dan hubungan antar modul, bagaimana modul disusun, digunakan kembali, dan mudah dibawa.

Pandangan fisik terutama untuk perancang sistem dan administrator yang perlu memahami lokasi fisik perangkat lunak, koneksi fisik antara node, penyebaran dan instalasi, dan skalabilitas.

Akhirnya, skenario membantu untuk menangkap persyaratan sehingga semua pemangku kepentingan memahami bagaimana sistem dimaksudkan untuk digunakan.

Setelah Anda memahami apa yang seharusnya disediakan oleh setiap tampilan, Anda dapat memilih notasi pemodelan apa yang akan digunakan dan pada tingkat detail apa yang diperlukan. Paragraf terakhir Bart terutama benar - Anda dapat menunjukkan berbagai tingkat detail dalam model UML Anda dengan berfokus pada elemen desain tertentu atau menggabungkan berbagai jenis diagram ke dalam satu set. Selain itu, Anda mungkin ingin mempertimbangkan melampaui UML ke notasi pemodelan lain untuk lebih menggambarkan arsitektur sistem Anda - SysML , pemodelan Entity-Relation , atau IDEF .

Alasan Anda tidak dapat menemukan pemetaan satu-ke-satu antara tampilan 4 + 1 Model Arsitektur dan berbagai diagram UML adalah karena pemetaan seperti itu tidak ada.

Apa yang semua penulis coba katakan dengan 'pemetaan' mereka adalah bahwa untuk setiap tampilan, ada satu set diagram UML yang dapat berguna untuk menyampaikan informasi yang ingin Anda sampaikan dalam tampilan itu.

Selain itu, beberapa diagram UML dapat digunakan dengan cara yang berbeda, dengan menekankan berbagai elemen dalam diagram, yang membuatnya berguna untuk banyak tampilan. Tetapi bahkan jika satu jenis diagram UML dapat digunakan dalam banyak tampilan, Anda akan menggambar diagram yang berbeda (atau serangkaian diagram) untuk setiap tampilan.

Meskipun saya setuju dengan pendekatan jawaban Thomas Owens untuk memenuhi kebutuhan pengguna akhir Anda, satu hal yang gagal disebutkan adalah bahwa alasan mengapa definisi asli dari "4 + 1 Lihat Model Arsitektur" oleh Kruchten tidak membuat referensi khusus untuk UML adalah karena artikel tersebut ditulis pada tahun 1995 (sebagaimana dinyatakan sebagai jawabannya), tetapi UML tidak benar-benar diadopsi sebagai standar sampai tahun 1997 .

Penggunaan Booch Notation secara terus-menerus dalam artikel tersebut menunjukkan bahwa menghubungkan setiap pandangan model dengan diagram UML tertentu bisa tepat, karena Grady Booch adalah salah satu orang yang terlibat dalam pengembangan UML.

Karena hal inilah maka banyak penulis yang berbeda menganggap diagram UML yang berbeda berlaku untuk setiap tampilan, karena beberapa diagram UML dapat dipertimbangkan dalam beberapa "abstraksi" Notasi Booch sehingga definisi asli dari model 4 + 1 bergantung pada untuk mewakili setiap tampilan.

Semoga ini menjelaskan sedikit lebih untuk orang lain yang melihat ini.

Apakah Anda masih menggunakan VCR yang Anda beli kembali pada 1995.? 4 +1 telah berlaku saat itu ketika perangkat lunak masih dalam masa pertumbuhan. Tetapi meskipun demikian, tidak ada yang pernah menggunakan lebih dari 2 atau 3 "tampilan". Dalam 20 tahun terakhir rekayasa perangkat lunak berubah. Saat ini, ruang lingkup / konteks dan konseptual dan logis dan fisik dan ... semuanya dibedakan. Banyak solusi COTS harus diintegrasikan, dan sebagainya. Hari ini, kita berbicara tentang peta lansekap, realisasi layanan dan puluhan pandangan dan sudut pandang lainnya. Cara terbaik untuk melihatnya adalah melalui kerangka taksonomi sederhana seperti Zachman: 6 view dan 6 viewpoints. Biarkan itu menjadi titik awal Anda. 6 pandangan adalah: konseptual kontekstual atau logika bisnis atau sistem pengiriman fisik atau teknologi atau artefak yang berfungsi perusahaan

6 sudut pandang adalah: data atau Apa fungsi atau Bagaimana jaringan atau Di mana orang atau Siapa waktu atau Kapan motivasi atau Mengapa

Mari kita lihat sebuah contoh. Jika kami hanya tertarik pada data, kami akan mulai dengan tampilan lingkup dan berkata, "Ruang lingkup kami adalah CRM". Dalam tampilan konseptual untuk sudut pandang data, kami akan membuat beberapa model semantik untuk CRM. Model akan konseptual, konsep informasi bisnis daripada objek data. Selanjutnya, dalam tampilan logis kami akan menghasilkan model data logis dari model konseptual CRM kami. Kami dapat menggunakan metodologi ER untuk menghasilkan model data logis. Kemudian, dalam tampilan fisik, kami akan menghasilkan model data fisik. Di sini, kita akan menentukan tipe data konkret untuk platform db pilihan kita, indeks dll. Akhirnya, dalam tampilan pengiriman kita akan memiliki skrip DDL kami, sementara dalam tampilan perusahaan yang berfungsi kita akan memiliki file biner yang digunakan pada beberapa server database dan dipetakan ke dalam struktur data internal vendor DBM. Kami ulangi ini untuk setiap sudut pandang atau kolom. Juga, jika ada lebih dari satu pemangku kepentingan, kami akan membuat lebih dari satu model untuk setiap kombinasi sudut pandang / tampilan. Sekarang setelah Anda memiliki taksonomi ini, Anda dapat menentukan sudut pandang dan pandangan Anda sendiri dan menyelaraskan ini ke dalam taksonomi ini. Misalnya, untuk inisiatif di tingkat perusahaan, sudut pandang berikut semuanya penting: aktor kerjasama aplikasi perilaku aplikasi kerja sama struktur aplikasi penggunaan fungsi bisnis proses bisnis proses kerjasama implementasi dan penyebaran struktur informasi infrastruktur penggunaan infrastruktur lanskap peta ikhtisar tinjauan layered realisasi layanan organisasi dll Sekarang setelah Anda memiliki taksonomi ini, Anda dapat menentukan sudut pandang dan pandangan Anda sendiri dan menyelaraskan ini ke dalam taksonomi ini. Misalnya, untuk inisiatif di tingkat perusahaan, sudut pandang berikut semuanya penting: aktor kerjasama aplikasi perilaku aplikasi kerja sama struktur aplikasi penggunaan fungsi bisnis proses bisnis proses kerjasama implementasi dan penyebaran struktur informasi infrastruktur penggunaan infrastruktur lanskap peta ikhtisar tinjauan layered realisasi layanan organisasi dll Sekarang setelah Anda memiliki taksonomi ini, Anda dapat menentukan sudut pandang dan pandangan Anda sendiri dan menyelaraskan ini ke dalam taksonomi ini. Misalnya, untuk inisiatif di tingkat perusahaan, sudut pandang berikut semuanya penting: aktor kerjasama aplikasi perilaku aplikasi kerja sama struktur aplikasi penggunaan fungsi bisnis proses bisnis proses kerjasama implementasi dan penyebaran struktur informasi infrastruktur penggunaan infrastruktur lanskap peta ikhtisar tinjauan layered realisasi layanan organisasi dll

Krutchen 4 +1 tidak dapat memenuhi semua kebutuhan ini