Dari pemodelan proses hingga merancang sistem otomatis (Bagian 2)

"Suatu hari dalam kehidupan tupai" atau dari proses pemodelan hingga merancang sistem akuntansi otomatis untuk nilai-nilai material "Squirrel-1.0" (Bagian 2)

Ilustrasi untuk A.S. Pushkin's Tsar Saltan digunakan, diterbitkan oleh Children's Literature, Moscow, 1949, Leningrad, gambar oleh K. Kuznetsov

Ringkasan dari seri sebelumnya

Pada bagian pertama, kami menggunakan area subjek "dongeng", terinspirasi oleh contoh-contoh studi diagram UML berdasarkan plot dongeng (lihat, misalnya, di sini [1]). Sebelum dimulainya pemodelan, kami sepakat untuk menggunakan beberapa elemen diagram Aktivitas dan mulai merumuskan perjanjian pemodelan. Berdasarkan perjanjian ini, pada tahap 1 kami menggambarkan proses dalam bentuk diagram Kegiatan, dan pada tahap 2 kami mengidentifikasi langkah-langkah proses yang diperlukan untuk otomatisasi (dan mungkin).

Biarkan saya mengingatkan Anda bahwa kami akan mengotomatiskan aktivitas akuntansi untuk nilai-nilai material yang muncul dalam proses ini.

...
Pulau itu terletak di laut, (E1, E2)
Kota di tribun pulau (E3, E1)
Dengan Gereja Kubah Emas, (E4)
Dengan menara dan taman; (E5, E6)
Pohon cemara tumbuh di depan istana, (E7, E8)
Dan di bawahnya adalah rumah kristal; (E9)
Tupai tinggal di sana secara manual (A1)
Sungguh penghibur! (A1)
Tupai menyanyikan lagu, (P1, A1)
Ya, gila menggerogoti segalanya, (P2)
Dan kacangnya tidak sederhana, (C1)
Semua kerang berwarna emas, (C2)
Kernel adalah zamrud murni; (C3)
Pelayan menjaga tupai, (P3, A2)
Mereka melayaninya pelayan yang berbeda (P4)
Dan petugas diperintahkan (A3)
Akun kacang yang ketat; (P5, C1)
Salut pasukannya; (P6, A4)
Dari cangkang, tuangkan koin, (P7, C2, C4)
Ya mengapung di seluruh dunia; (P8)
Gadis menuangkan zamrud (P9, A5, C3)
Di dapur, tapi di latar belakang; (E10, E11)
...
(A.S. Pushkin "Kisah Tsar Saltan, tentang pahlawannya yang mulia dan kuat Pangeran Gvidon Saltanovich dan Putri Angsa yang indah," seperti yang diyakini, pengobatan gratis dari kisah rakyat "Setinggi Emas, Siku dari Tangan dalam Perak", yang direkam oleh Pushkin dengan berbagai cara )

Dalam contoh ini, saya menggunakan lingkungan Enterprise Architect dari perusahaan Australia Sparx Systems [2], dan sebagai bagian dari sesi pelatihan saya menggunakan Modelio [3].
Biarkan saya mengingatkan Anda bahwa prosesnya berbeda, Anda bisa berkenalan, misalnya, di sini [4] dan di sini [5].
Untuk informasi lebih lanjut tentang pendekatan yang diterapkan untuk pemodelan dan perancangan lihat [6, 7].
Lihat spesifikasi UML lengkap di sini [8].

Sekarang kita siap untuk melangkah ke langkah berikutnya dan mulai merancang fungsi sistem dan organisasi internalnya. Penomoran angka akan terus berlanjut.

Tahap 3. Langkah otomatis harus sesuai dengan fungsi atau fungsi sistem

Sistem otomatis yang dikembangkan (AS) dirancang untuk menjaga catatan ketat kacang, ingat? Untuk setiap langkah yang dipilih (lihat Gambar 3, Gambar 4 di bagian 1 ), yang akan kamiotomatiskan, kami tuliskan persyaratan fungsional, dengan menerapkan kira-kira konstruksi berikut: “Sistem harus memiliki kesempatan untuk diimplementasikan ...” dan mengembangkan diagram Use-case. Sekarang kami sebenarnya melengkapi perjanjian pemodelan kami dengan aturan baru. Biarkan saya menjelaskan elemen mana yang akan kita gunakan.

Antara "Peran Pengguna" dan "Fungsi" kita akan menggunakan asosiasi asosiasi (Gambar 5), yang berarti bahwa untuk pengguna dengan peran ini, eksekusi fungsi ini tersedia.

Gambar 5. Menggunakan komunikasi tipe asosiasi

Dari "Fungsi" ke "Persyaratan" kami menggambar hubungan "Implementasi" (Gambar 6) untuk menunjukkan bahwa persyaratan ini akan diimplementasikan oleh fungsi-fungsi ini, hubungan tersebut dapat "banyak-ke-banyak", yaitu. satu fungsi mungkin terlibat dalam implementasi beberapa persyaratan, dan lebih dari satu fungsi mungkin diperlukan untuk mengimplementasikan suatu persyaratan.

Gambar 6. Menggunakan hubungan tipe "Implementasi"

Jika satu fungsi mensyaratkan untuk pelaksanaannya bahwa fungsi lain harus dilakukan, dan itu perlu, kita akan menggunakan hubungan "Ketergantungan" dengan stereotip "Sertakan" - inklusi (Gambar 7). Jika pelaksanaan fungsi tambahan diperlukan dalam kondisi tertentu, maka kami akan menggunakan hubungan "Ketergantungan" dengan stereotip "Perpanjang" - ekstensi. Semuanya sangat mudah diingat: "Sertakan" - SELALU, dan "Perpanjang" - TERKADANG.

Gambar 7. Menggunakan hubungan tipe “Dependency (inclusion)”

Hasilnya, diagram kita akan terlihat seperti ini (Gambar 8).

Gambar 8. Diagram use-case (model fungsional AS)

Selain itu, diagram use-case digunakan untuk memodelkan peran pengguna (Gambar 9).

Gambar 9. Diagram use-case (peran pengguna pembicara)

Tahap 4. Kami menggambarkan organisasi internal AS menggunakan diagram kelas

Dengan menggunakan informasi tentang input dan output artefak dari proses kami (lihat Diagram Kegiatan - Gambar 2, Gambar 3, Gambar 4), kami akan mengembangkan diagram kelas. Kami akan menggunakan elemen pemodelan "Kelas" dan berbagai jenis koneksi di antara mereka.

Untuk menunjukkan hubungan "seluruh-bagian", kita akan menggunakan hubungan tipe "Agregasi" (Gambar 10): mur adalah keseluruhan, dan shell dan kernel adalah bagian.

Gambar 10. Hubungan "seluruh bagian"

Akibatnya, sebuah fragmen dari diagram kita akan terlihat seperti ini (Gambar 11). Warna menunjukkan kelas yang kami identifikasi langsung dalam deskripsi teks dari proses.

Gambar 11. Diagram kelas

Diagram kelas juga digunakan untuk memodelkan artefak lain - tidak hanya yang akan terkait dengan model konseptual dari proses otomatis akuntansi untuk nilai-nilai material, tetapi yang terkait dengan lingkungan runtime - lingkungan (Gambar 12) dan proses "tetangga" (Gambar 13), yang dapat untuk memengaruhi 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 warisan menunjukkan generalisasi dari berbagai bangunan, kelas "anak", di bawah kelas "induk" generalisasi "Struktur".

Gambar 13. Diagram kelas (informasi tambahan tentang artefak)

"Respons terhadap situasi" tergantung pada "Data inspeksi visual". Untuk beberapa hubungan ketergantungan, stereotip "jejak" digunakan untuk menunjukkan penelusuran kelas yang tidak secara eksplisit ditunjukkan dalam deskripsi proses, tetapi yang diperlukan untuk otomasinya, ke kelas untuk instance yang terdapat indikasi pasti dalam deskripsi kami.

Tahap 5. Kami menganalisis catatan di trek "Aturan Bisnis"

Aturan ditunjukkan (lihat Gambar 2 di bagian 1 ):

1. kebutuhan untuk membagi salah satu langkah menjadi 2 bagian, bagian kedua mulai dilakukan hanya dalam kondisi tertentu;
2. Pengangkatan untuk melakukan penghitungan kacang dari pejabat tertentu;
3. teknik teknis (warna putih elemen), yang menunjukkan bahwa elemen tersebut tidak secara eksplisit ditunjukkan dalam deskripsi proses.

Perlu dicatat bahwa kami sudah menggunakan semua aturan ini ketika mengembangkan diagram.

Pengamatan penutup

Jadi, kami melewati 5 tahap dan membangun 3 jenis diagram. Tambahkan sedikit komentar tentang organisasi model kami di lingkungan pemodelan. Ada sejumlah besar kerangka kerja yang membantu untuk menyusun model yang sedang dikembangkan, tetapi ini bukan subjek dari artikel ini, oleh karena itu kami akan membatasi diri pada rangkaian paket sederhana berikut untuk melakukan proyek kami secara tertib: Proses bisnis, model fungsional, Artefak, Partisipan dan Lingkungan (Gambar 14).

Gambar 14. Struktur paket proyek

Dengan demikian, kami telah mengembangkan model yang konsisten yang menggambarkan sistem akuntansi untuk nilai-nilai material dari berbagai sudut: model proses bisnis otomatis, model fungsional, dan model organisasi internal sistem pada level konseptual.

Dari pemodelan proses hingga merancang sistem otomatis (Bagian 1)