Get best of the week

UML untuk pengembang

Internet penuh dengan artikel tentang UML, Anda akan menemukan ratusan contoh untuk setiap jenis diagram, dan buat sendiri tanpa masalah, notasinya tidak rumit. Tetapi apakah benar-benar perlu menghabiskan waktu untuk hal ini? Kekayaan pengalaman kami mengatakan ya. Jika Anda memiliki lebih dari 2 orang dalam satu tim dan proyek 3 bulan atau lebih, maka sudah masuk akal untuk menggambar 2-3 jenis diagram. Tim kami memiliki lebih dari 30 orang, sebuah proyek yang bertahan lebih dari 3 tahun, dan kami menggunakan ... 2-3 jenis diagram.

Notasi UML berlebihan. Di sisi lain, itu tidak cukup untuk desain sistem terdistribusi, dan di sini Archimate membantu kita. Dalam artikel ini, kami akan memberi tahu Anda apa yang benar-benar berguna dari semua varietas ini, dan mempertimbangkan siklus penuh pembuatan diagram untuk proyek sebagai contoh.

Apa yang akan kita tarik?


Jika tujuan Anda "cepat dan indah" (misalnya, untuk presentasi atau untuk artikel ini), maka Visio lebih dari cocok: editornya nyaman dan memaafkan penyimpangan dari notasi.

Jika Anda terlibat dalam desain, Anda akan membutuhkan sistem lengkap dengan dukungan untuk hubungan antar diagram. Kami menggunakan produk Enterprise Architect, murah dan ceria.
Perbandingan sistem desain dan cerita tentang cara menggunakannya dengan benar adalah topik untuk artikel terpisah.

Tugas teknis


Kami akan merancang aplikasi seluler hipotetis untuk belajar bahasa asing. Kerangka acuan biasanya disiapkan oleh analis yang akan menyiapkan batch diagram pertama. Pengembang, dalam hal ini, hanya diminta untuk membacanya dengan benar.

Diagram paling sederhana adalah Use Case:



Diagram menunjukkan jenis pengguna dan daftar fungsi atau kelompok fungsi yang terkait dengannya. Elemen yang disorot dengan warna biru yang tidak ada dalam UML, tetapi sering kurang: Persyaratan - Persyaratan (dari notasi Archimate), penyempurnaan fungsi.

Anda bertanya - dan apa gunanya? Lagi pula, daftar fungsi dapat ditentukan secara sederhana dalam teks, dalam satu daftar ringkas! Dan Anda akan benar, tetapi ada nuansa.

  1. Beberapa fungsi berhubungan dengan beberapa pengguna, sulit untuk menampilkan teks.
  2. Saat Anda menggambar semua fungsi dan persyaratan dalam sistem desain, Anda kemudian dapat mengunggahnya ke Jira yang sama, dan kemudian mengaitkannya dengan tugas dan bug, yang menyederhanakan manajemen proyek.

Mengapa kami mencampur UML dan Arsip dalam diagram yang sama? Anda tidak perlu secara ketat mengikuti notasi, Anda tidak harus lulus ujian di universitas dengan ini, tetapi berkomunikasi dengan tim, yang Anda mempersiapkan semuanya.

Mengapa kami menggunakan garis daripada panah untuk menghubungkan elemen? Karena tidak ada yang ingat seperti apa panah "Generalisasi" dan "Ekstensi", dan seperti apa umumnya. Semakin sederhana Anda menggambar, semakin banyak orang akan memahami bagan tanpa partisipasi Anda.

Jenis diagram kedua yang dapat Anda temui dalam tugas teknis adalah Activity diagram:



Di sini, semuanya jelas bagi pengembang, kecuali untuk satu hal: mengapa AI melakukan panggilan Mahasiswa? Tidak. Diagram ini dibuat oleh analis, bukan programmer, mereka tidak tahu di mana klien berada, tetapi di mana server berada, dan mereka tidak tertarik pada aliran data. Pada diagram Aktivitas, Anda melihat urutan tindakan dan tidak lebih. Bagaimana cara membuat kode dari ini? Kami lolos ke tahap desain.

Desain arsitektur


Arsitektur aplikasi seluler jelas: klien, server, basis data. Jika kita merancang sesuatu yang serius, maka kita harus berhati-hati membagi proyek menjadi Subsistem, dalam kasus kita setidaknya akan menjadi:

  • Subsistem Pemesanan Pelajaran
  • Subsistem Pelatihan Web
  • Penagihan
  • Subsistem Manajemen Perekaman Suara

Subsistem harus diisolasi satu sama lain: basis datanya sendiri tanpa koneksi relasional dengan subsistem lain, komunikasi antar subsistem hanya melalui API. Subsistem dapat berupa seperangkat layanan microser atau monolit, sesuai kebijakan Anda.

Anda dapat memberikan setiap subsistem kepada tim pengembangan yang berdedikasi, mereka akan membenamkan diri dalam topik mereka dan tidak akan terlalu mengganggu rekan kerja dengan komitmen yang tidak terduga.

Untuk setiap subsistem, diperlukan skema arsitektur , bagaimana cara menggambarnya dengan benar? Tidak ada diagram yang cocok di UML untuk ini, mari kita lihat Archimate:



Bahkan tanpa pengetahuan notasi, diagram pada umumnya dapat dibaca. Ingatlah bahwa 90% anggota tim Anda tidak mengenal UML, apalagi Arsipkan, dan mereka tidak akan pernah mempelajari notasi ini, jadi fokuslah pada prasasti. Namun demikian,



beberapa kata tentang kubus dan panah: Anda dapat dengan mudah menemukan spesifikasi Arsip lengkap.

Warna - sesuai selera Anda, notasi tidak mengaturnya dengan cara apa pun. Warna subsistem saat ini dengan satu warna, subsistem yang berdekatan dengan yang kedua, sistem eksternal dengan yang ketiga, ini sangat meningkatkan keterbacaan sirkuit.

Diagram hanya menggunakan dua jenis panah: Flow dan Access. Alurnya menunjukkan arah transfer data, dan Panggilan - siapa yang berbicara kepada siapa. Panah aliran harus dipahami dengan benar:



Diagram alir dari aplikasi seluler ke server tidak diperlihatkan dalam diagram, meskipun sebenarnya itu (aliran "Permintaan data" lebih dulu). Ini dilakukan untuk membuat skema lebih mudah dibaca: kami hanya menunjukkan yang paling penting. Fakta bahwa ada juga permintaan data awal sudah terbukti dari kubus dengan API prasasti.

Detail


Dua diagram terakhir, yang sangat berguna (pembaca yang penuh perhatian, tentu saja, memperhatikan bahwa tidak ada lagi 2-3 jenis diagram): Diagram urutan (Diagram kelas) dan Diagram Kelas (Diagram kelas, tetapi tidak untuk kelas sama sekali).

Kadang-kadang interaksi client-server multi-stage, menggunakan sumber daya ketiga. Misalnya, otorisasi dengan Oauth2: deskripsi tekstual dari proses ini sangat sulit untuk dipahami. Di sini diagram Sequence akan membantu kita :



Implementasi Oauth2 ini bukan referensi, mungkin ada banyak opsi. Hal yang paling penting untuk dipahami dalam diagram adalah bahwa tidak ada aliran data dalam diagram ini, hanya Panggilan dan Jawaban untuk panggilan. Meskipun ini tidak menghentikan kami untuk menentukan aliran dengan teks pada panah.

Ketika Anda mempelajari studi diagram Sequence, Anda akan menemukan bahwa itu memungkinkan Anda untuk menampilkan loop dan cabang, tetapi jangan menyalahgunakannya: Anda tidak perlu menggambar cabang “Jika pengguna memilih otorisasi lokal,” dan “Jika Anda memilih otorisasi FB,” sebagai gantinya, menggambar dua skema untuk setiap opsi. Kondisi, terutama yang bersarang, pada diagram Sequence sangat mengurangi keterbacaan sirkuit.

Diagram terakhir (tidak hari ini, tetapi secara umum) adalah Diagram Kelas . Namanya berbicara, diasumsikan bahwa dengan bantuan kelasnya akan dirancang. Di masa lalu editor teks DOS, ini mungkin dibenarkan, tetapi lingkungan pengembangan modern memungkinkan Anda untuk merancang dan menganalisis kelas tanpa meninggalkan tema gelap dan terang mereka.

Tetapi aplikasi praktis Class Diagram masih tetap - desain database:



Jika Anda tahu apa itu database Relational, maka ini lebih dari jelas. Atribut pada diagram tidak sepenuhnya masuk, hanya hubungan, tipe data, dan terkadang batasan yang ditunjukkan.

Jangan mencoba menggambarnya di Visio, Arsitek Perusahaan atau yang setara. Untuk desain basis data, ada banyak alat khusus yang dirancang untuk DBMS tertentu, menggunakannya.

Itu saja. Dari semua diagram di UML dan Archimate, dalam praktiknya, lebih dari cukup tercantum. Berapa banyak diagram dari setiap jenis yang dibutuhkan untuk suatu proyek? Haruskah saya menggambar mereka untuk setiap proses dan subsistem? Aturan utamanya adalah diagram menyertai deskripsi teks, hanya diperlukan jika teksnya tidak cukup, mis. di mana tim tidak mengerti Anda.

Terima kasih atas perhatian Anda, ada perusahaan Produk Perangkat Lunak bersama Anda.

More articles:


All Articles