“Suatu hari dalam kehidupan seekor tupai” atau dari pemodelan proses hingga desain sistem akuntansi kekayaan otomatis “Belka-1.0” (Bagian 2)
Ringkasan episode sebelumnya
В Kami menggunakan domain “dongeng”, yang terinspirasi oleh contoh pembelajaran diagram UML berdasarkan plot dongeng (lihat, misalnya, [1]). Sebelum pemodelan dimulai, kami menyepakati penggunaan beberapa elemen diagram Aktivitas dan mulai membentuk kesepakatan pemodelan. Dengan mempertimbangkan kesepakatan ini, pada tahap pertama kami menggambarkan proses dalam bentuk diagram Aktivitas, dan pada tahap kedua kami mengidentifikasi langkah-langkah proses yang memerlukan (dan memungkinkan) otomatisasi.
Izinkan saya mengingatkan Anda bahwa kami akan mengotomatiskan aktivitas akuntansi aset material yang timbul dalam proses ini.
...
Sebuah pulau terletak di laut, (E1, E2)
Ada hujan es di pulau (E3, E1)
Dengan gereja berkubah emas, (E4)
Dengan menara dan taman; (E5, E6)
Pohon cemara tumbuh di depan istana, (E7, E8)
Dan di bawahnya ada rumah kristal; (E9)
Seekor tupai jinak tinggal di sana, (A1)
Ya, sungguh sebuah petualangan! (A1)
Tupai menyanyikan lagu, (P1, A1)
Ya, dia terus menggigit kacang, (P2)
Tapi kacang itu tidak sederhana, (C1)
Semua cangkang berwarna emas, (C2)
Intinya adalah zamrud murni; (C3)
Pelayan menjaga tupai, (P3,A2)
Mereka melayaninya sebagai berbagai pelayan (P4)
Dan seorang juru tulis ditugaskan (A3)
Laporan ketat tentang orang gila adalah beritanya; (P5, C1)
Tentara memberi hormat padanya; (P6, A4)
Sebuah koin dituangkan dari cangkangnya, (P7, C2, C4)
Biarkan mereka berkeliling dunia; (P8)
Gadis menuangkan zamrud (P9, A5, C3)
Ke dalam gudang, dan berlindung; (E10, E11)
...
(A.S. Pushkin “Kisah Tsar Saltan, pahlawannya yang mulia dan perkasa Pangeran Guidon Saltanovich dan Putri Angsa yang cantik”, )
Dalam contoh ini, saya menggunakan lingkungan Enterprise Architect dari perusahaan Australia. [2], dan selama sesi pelatihan saya gunakan [3].
Izinkan saya mengingatkan Anda bahwa ada proses yang berbeda, Anda bisa berkenalan, misalnya, [4] dan [5].
Untuk rincian lebih lanjut tentang pendekatan yang diterapkan pada pemodelan dan desain, lihat [6, 7].
Untuk spesifikasi UML selengkapnya, lihat [8].
Kami sekarang siap untuk melanjutkan ke langkah berikutnya dan mulai merancang fungsionalitas sistem dan organisasi internal. Penomoran gambar akan terus berlanjut.
Tahap 3. Tahap otomasi harus dikaitkan dengan suatu fungsi atau fungsi sistem
Sistem otomatis (AS) yang sedang dikembangkan dirancang untuk menjaga pencatatan kacang secara ketat, ingat? Untuk setiap langkah yang disorot (lihat Gambar 3, Gambar 4 ), yang akan kita otomatisasi, tuliskan persyaratan fungsional menggunakan kira-kira konstruksi berikut: "Sistem harus mengimplementasikan kemampuan..." dan mengembangkan diagram Use-case. Kami sekarang sebenarnya menambahkan aturan baru ke dalam perjanjian pemodelan kami. Izinkan saya menjelaskan elemen apa yang akan kita gunakan.
Kami akan menggunakan koneksi "Asosiasi" antara "Peran Pengguna" dan "Fungsi" (Gambar 5), yang berarti bahwa pengguna dengan peran ini dapat menjalankan fungsi ini.
Gambar 5. Menggunakan relasi tipe Asosiasi
Dari “Fungsi” ke “Persyaratan” kita akan menggambar hubungan “Implementasi” (Gambar 6) untuk menunjukkan bahwa persyaratan ini akan diterapkan oleh fungsi-fungsi ini; hubungannya bisa “banyak ke banyak”, yaitu Satu fungsi mungkin terlibat dalam penerapan beberapa persyaratan, dan lebih dari satu fungsi mungkin diperlukan untuk mengimplementasikan suatu persyaratan.
Gambar 6. Menggunakan hubungan tipe “Implementasi”.
Jika satu fungsi memerlukan eksekusi beberapa fungsi lain, dan tentu saja, kita akan menggunakan koneksi "Ketergantungan" dengan stereotip "Sertakan" (Gambar 7). Jika eksekusi fungsi tambahan diperlukan dalam kondisi tertentu, maka kita akan menggunakan koneksi “Dependency” dengan stereotip “Extend”. Semuanya sangat mudah diingat: “Sertakan” SELALU, dan “Perluas” KADANG.
Gambar 7. Menggunakan hubungan “Ketergantungan (inklusi)”.
Hasilnya, diagram kita akan terlihat seperti ini (Gambar 8).
Gambar 8. Use-case diagram (model fungsional AC)
Selain itu, diagram Use-case digunakan untuk memodelkan peran pengguna (Gambar 9).
Gambar 9. Use-case diagram (peran pengguna AS)
Tahap 4. Mari kita gambarkan organisasi internal AS menggunakan diagram kelas
Dengan menggunakan informasi tentang artefak masukan dan keluaran dari proses kita (lihat diagram aktivitas - Gambar 2, Gambar 3, Gambar 4), kita akan mengembangkan diagram kelas. Kami akan menggunakan elemen pemodelan “Kelas” dan berbagai jenis koneksi di antara mereka.
Untuk menunjukkan hubungan “keseluruhan-bagian”, kita akan menggunakan hubungan tipe “Agregasi” (Gambar 10): kacang adalah keseluruhannya, dan cangkang serta kernel adalah bagian-bagiannya.
Gambar 10. Hubungan seluruh bagian
Hasilnya, bagian diagram kita akan terlihat seperti ini (Gambar 11). Kelas-kelas yang kami soroti langsung dalam deskripsi teks proses ditandai dengan warna.
Gambar 11. Diagram kelas
Diagram kelas juga digunakan untuk memodelkan artefak lain - tidak hanya artefak yang akan terkait dengan model konseptual proses otomatis akuntansi aset material, tetapi juga terkait dengan lingkungan eksekusi - lingkungan (Gambar 12) dan lingkungan “tetangga”. proses (Gambar 13) yang dapat mempengaruhi proses otomatis, tetapi belum menjadi fokus perhatian kami (kami berasumsi bahwa sistem akan berkembang dan informasi ini akan berguna).
Gambar 12. Diagram kelas (lingkungan)
Hubungan pewarisan menunjukkan generalisasi berbagai bangunan, kelas “anak”, di bawah “Bangunan” kelas “induk” yang digeneralisasi.
Gambar 13. Diagram kelas (informasi tambahan tentang artefak)
“Reaksi terhadap situasi” bergantung pada “Data kontrol visual”. Untuk beberapa hubungan ketergantungan, stereotip "jejak" digunakan untuk menunjukkan penelusuran kelas yang tidak diidentifikasi secara eksplisit dalam deskripsi proses, namun diperlukan untuk mengotomatiskannya, ke kelas yang instance-nya direferensikan secara eksplisit dalam deskripsi kami.
Tahap 5. Mari kita menganalisis catatan pada jalur “Aturan Bisnis”.
Aturannya telah ditentukan (lihat Gambar 2 ):
- kebutuhan untuk membagi salah satu langkah menjadi 2 bagian, bagian kedua mulai dilakukan hanya dalam kondisi tertentu;
- penunjukan pejabat tertentu untuk melaksanakan pembukuan kacang-kacangan;
- suatu teknik (warna putih elemen) yang menunjukkan bahwa elemen tersebut tidak ditentukan secara eksplisit dalam deskripsi proses.
Perlu dicatat bahwa kami telah menggunakan semua aturan ini saat mengembangkan diagram.
Catatan akhir
Jadi, kami melalui 5 tahap dan membuat 3 jenis diagram. Saya akan menambahkan komentar kecil tentang pengorganisasian model kita dalam lingkungan pemodelan. Ada sejumlah besar kerangka kerja yang membantu menyusun model yang sedang dikembangkan, tetapi ini bukan subjek artikel ini, jadi kami akan membatasi diri pada kumpulan paket sederhana berikut untuk pengelolaan proyek kami secara teratur: Proses Bisnis, Model Fungsional , Artefak, Peserta dan Lingkungan (Gambar 14).
Gambar 14. Struktur paket proyek
Oleh karena itu, kami telah mengembangkan model yang konsisten yang menggambarkan sistem akuntansi material dari berbagai aspek: model proses bisnis otomatis, model fungsional, dan model organisasi internal sistem pada tingkat konseptual.
Daftar sumber
- Situs web "UML2.ru". Forum Komunitas Analis. Bagian umum. Contoh. Contoh dongeng yang diformat diagram UML. [Sumber daya elektronik] Mode akses: Internet:
- Situs web Sistem Sparx. [Sumber daya elektronik] Mode akses: Internet:
- Situs web Modelio. [Sumber daya elektronik] Mode akses: Internet:
- Kamus Ensiklopedis Besar. Proses (interpretasi). [Sumber daya elektronik] Mode akses: Internet:
- Website "Organisasi Manajemen yang Efektif". Blog. Kategori "Manajemen Proses Bisnis". Definisi proses bisnis. [Sumber daya elektronik] Mode akses: Internet:
- Sertifikat No. 18249 tentang pendaftaran dan penyimpanan suatu karya kegiatan intelektual. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Naskah alat peraga berjudul “Pemodelan Mata Pelajaran Menggunakan Enterprise Architect” // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Pemodelan proses bisnis. — M.: KURSUS, SIC INFRA-M, EBS Znanium.com. — 2017.
- Spesifikasi OMG Unified Modelling Language (OMG UML). Versi 2.5.1. [Sumber daya elektronik] Mode akses: Internet:
Sumber: www.habr.com