Dari pemodelan proses hingga merancang sistem otomatis (Bagian 1)

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

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

Apa hubungan "tupai" dengan itu?

Saya akan segera menjelaskan apa itu "tupai". Setelah tersandung di Web tentang proyek-proyek menyenangkan untuk mempelajari UML, mengandalkan bidang studi yang dipinjam dari plot dongeng (misalnya, di sini [1]), saya juga memutuskan untuk menyiapkan contoh serupa untuk siswa saya sehingga saya dapat mempelajari hanya tiga jenis diagram untuk memulai dengan: Kegiatan Diagram, Use-case Diagram dan Class Diagram. Saya sengaja tidak menerjemahkan nama-nama diagram ke dalam bahasa Rusia untuk menghindari perselisihan tentang "kesulitan terjemahan." Untuk apa - saya akan jelaskan sedikit nanti. Dalam contoh ini, saya menggunakan lingkungan Enterprise Architect dari perusahaan Australia Sparx Systems [2] - alat yang bagus untuk harga yang wajar. Dan sebagai bagian dari pelatihan, saya menggunakan Modelio [3], alat gratis yang bagus untuk desain berorientasi objek yang mendukung standar UML2.0 dan BPMN, tanpa embel-embel yang tidak perlu dalam hal kemampuan visual, tetapi cukup memadai untuk mempelajari dasar-dasar bahasa.

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, putranya pahlawan yang mulia dan kuat Pangeran Gvidon Saltanovich dan Putri Swans yang cantik," karya tentang dongeng itu dimulai pada tahun 1822, kisah pertama diterbitkan oleh Pushkin dalam koleksi "Puisi A. Pushkin ”(bagian III, 1832, hlm. 130-181) - omong-omong 10 tahun dari desain hingga publikasi!

Sedikit tentang kode yang ditulis di sebelah kanan baris. "A" (dari "Aktor") berarti bahwa baris tersebut berisi informasi tentang peserta dalam proses. "C" (dari "Kelas") - informasi tentang objek kelas yang diproses selama pelaksanaan proses. "E" (dari "Lingkungan") - informasi tentang objek kelas yang menjadi ciri lingkungan eksekusi proses. "P" (dari "Proses") - informasi tentang proses itu sendiri.

Omong-omong, definisi proses yang akurat juga mengklaim menjadi penyebab perselisihan metodologis, jika hanya karena prosesnya berbeda: bisnis, produksi, teknologi, dll. dll. (Anda bisa berkenalan, misalnya, di sini [4] dan di sini [5]). Untuk menghindari kontroversi, kami setuju bahwa proses tersebut menarik minat kami dalam hal pengulangan dalam waktu dan kebutuhan untuk otomatisasi , yaitu. mengalihkan pelaksanaan bagian proses operasi ke sistem otomatis.

Catatan Aplikasi Diagram Aktivitas

Mari kita mulai memodelkan proses kita dan menggunakan diagram Kegiatan untuk ini. Pertama, saya akan menjelaskan bagaimana kode di atas akan digunakan dalam model. Lebih mudah dijelaskan dengan contoh grafis, tetapi pada saat yang sama kami akan menganalisis beberapa (hampir semua elemen yang kami butuhkan) elemen dari diagram Kegiatan.
Mari kita menganalisis fragmen berikut:

...
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)
...

Kami memiliki dua langkah proses P1 dan P2, peserta A1, dan objek dari tiga kelas yang berbeda: objek kelas C1 tiba pada input langkah, objek kelas C2 dan C3 diperoleh pada output, sebagai hasil dari aktivitas langkah ini P2 dari proses kami. Untuk diagram kita menggunakan elemen pemodelan berikut.

Sebuah fragmen dari proses kami dapat direpresentasikan seperti ini (Gambar 1).

Gambar 1. Sebuah fragmen dari diagram Kegiatan

Untuk mengatur ruang dan struktur diagram Kegiatan, kami akan menggunakan pendekatan yang tidak terlalu standar, dalam hal penggunaan klasik notasi UML. Tetapi ada beberapa alasan untuk ini. Pertama, tepat sebelum dimulainya pemodelan, kami akan menyusun apa yang disebut perjanjian pemodelan , di mana kami memperbaiki semua fitur menggunakan notasi. Kedua, pendekatan ini telah berulang kali berhasil diterapkan pada tahap pemodelan bisnis dalam proyek nyata untuk membuat sistem perangkat lunak, hasilnya dicatat oleh tim penulis kecil kami dalam subjek hak cipta yang sesuai [6], dan juga digunakan dalam manual pelatihan [7]. Untuk diagram Kegiatan, kami menentukan bahwa struktur bidang diagram disusun menggunakan jalur "berenang" - jalur Berenang. Nama trek akan sesuai dengan jenis elemen bagan yang akan ditempatkan di trek ini.

"Input dan output artefak": Objek - objek yang digunakan atau merupakan hasil dari beberapa langkah proses akan terletak di trek ini.
"Langkah-langkah proses": di sini kita menempatkan unsur-unsur Kegiatan - tindakan para peserta dalam proses.
"Peserta": jalur untuk elemen yang akan menunjukkan peran pelaksana tindakan dalam proses kami, bagi mereka kami akan menggunakan elemen Obyek pemodelan objek yang sama - sebuah objek, tetapi menambahkan stereotip "Aktor" ke dalamnya.
Lagu berikutnya disebut "Aturan Bisnis" dan di trek ini kita akan menempatkan dalam bentuk teks aturan untuk menyelesaikan langkah-langkah proses, dan untuk ini kita akan menggunakan elemen pemodelan Catatan - catatan.
Kami akan berhenti di sini, meskipun kami juga dapat menggunakan trek "Alat" untuk mengumpulkan informasi tentang tingkat otomatisasi proses. Lagu "Posisi dan unit peserta" juga dapat berguna, dapat digunakan untuk menghubungkan peran dengan posisi dan unit peserta dalam proses.

Semua yang baru saja saya jelaskan adalah bagian dari perjanjian pemodelan , bagian dari perjanjian ini menyangkut aturan untuk mengatur satu diagram dan, dengan demikian, aturan untuk menulis dan membacanya.

"Resep"

Sekarang kita akan mempertimbangkan opsi pemodelan sistem dari diagram Activity. Ini hanya salah satu opsi, saya perhatikan bahwa dia, tentu saja, bukan satu-satunya. Diagram Aktivitas akan menarik minat kita dalam hal perannya dalam beralih dari pemodelan proses ke merancang sistem otomatis. Untuk melakukan ini, kami akan mematuhi rekomendasi metodologis - semacam resep yang hanya terdiri dari lima tahap dan melibatkan pengembangan hanya tiga jenis diagram. Menerapkan resep ini akan membantu untuk memperoleh deskripsi formal tentang proses yang ingin kita otomatisasi, dan untuk mengumpulkan data untuk desain sistem. Dan bagi siswa di awal belajar UML, ini adalah semacam pelampung yang tidak akan membiarkan Anda tenggelam dalam semua berbagai alat dan teknik visual yang ada di UML dan alat pemodelan modern.

Di sini, pada kenyataannya, resep itu sendiri, dan kemudian diagram yang dibangun untuk area subjek "dongeng" kita ikuti.

Tahap 1. Kami menggambarkan proses dalam bentuk diagram Kegiatan. Untuk proses di mana lebih dari 10 langkah disorot, masuk akal untuk menerapkan prinsip dekomposisi langkah-langkah proses untuk meningkatkan keterbacaan diagram.

Tahap 2. Kami menyoroti apa yang bisa otomatis (langkah-langkah bisa, misalnya, disorot dalam diagram).

Tahap 3. Langkah otomatis perlu sesuai dengan fungsi atau fungsi sistem (hubungannya bisa banyak-ke-banyak), menggambar diagram use-case. Ini adalah fungsi dari sistem kami.

Tahap 4. Kami menggambarkan organisasi internal AS menggunakan diagram kelas - Kelas. Jalur renang "Input dan output objek (dokumen)" pada diagram Aktivitas adalah dasar untuk membangun model objek dan model hubungan entitas.

Tahap 5. Mari kita menganalisis catatan pada jalur "Aturan Bisnis" , mereka memberikan berbagai macam batasan dan kondisi, secara bertahap berubah menjadi persyaratan non-fungsional.
Seperangkat diagram yang dihasilkan (Activity, Use-case, Class) memberi kami deskripsi yang diformalkan dalam notasi yang cukup ketat, yaitu memiliki bacaan yang jelas. Sekarang dimungkinkan untuk mengembangkan kerangka acuan, memperjelas spesifikasi persyaratan, dll.

Mari kita mulai membuat model.

Tahap 1. Kami menggambarkan proses dalam bentuk diagram Kegiatan.

Biarkan saya mengingatkan Anda bahwa kami menyusun bidang bagan dengan bantuan jalur "berenang", di setiap jalur ada elemen dengan tipe yang sama (Gambar 2). Selain elemen bagan yang dijelaskan di atas, kami akan menggunakan elemen tambahan, mari kita jelaskan dari.

Keputusan menunjukkan titik cabang dari proses kami pada diagram, dan gabungan arus (Gabung) - titik reuni mereka. Dalam tanda kurung pada transisi, kondisi transisi dicatat.

Antara dua sinkronisasi (Fork) kami akan menunjukkan cabang paralel dari proses tersebut.
Proses kami hanya dapat memiliki satu awal - satu titik masuk (Awal). Tetapi final (Final) mungkin beberapa, tetapi tidak untuk diagram spesifik kami.

Ada banyak panah, dengan sejumlah besar elemen dan tautan, Anda dapat pertama-tama memilih tahapan proses, dan kemudian menguraikan tahapan-tahapan ini. Tetapi demi kejelasan, saya ingin menunjukkan proses "dongeng" kami secara keseluruhan pada satu diagram, sementara, tentu saja, kita perlu memastikan bahwa panah tidak "saling menempel", kita dapat secara akurat melacak apa yang terhubung dengan apa.

Gambar 2. Diagram aktivitas - tampilan umum dari proses

Karena dalam garis puitis beberapa detail dari proses dihilangkan, saya harus mengembalikannya, mereka ditunjukkan oleh elemen dengan latar belakang putih. Rincian ini termasuk langkah “Transfer / Penerimaan untuk Penyimpanan dan Pemrosesan” dan beberapa artefak input dan output. Perlu dicatat bahwa langkah ini juga tidak sepenuhnya mengungkapkan prosesnya, karena kita perlu secara terpisah menunjukkan langkah transfer dan langkah penerimaan, dan bahkan untuk shell menambahkan langkah terpisah, dan juga menduga bahwa pertama semua nilai material ini harus disimpan sementara di suatu tempat, dll. dll.
Kami juga menarik perhatian pada fakta bahwa pertanyaan tentang asal-usul kacang tetap tidak terjawab - dari mana mereka berasal dan bagaimana mereka mendapatkan protein? Dan pertanyaan ini (disorot dengan warna merah pada font di note - elemen Note) memerlukan penelitian terpisah! Dan begitu analis bekerja - mengumpulkan informasi sedikit demi sedikit, membuat asumsi dan mendapatkan "baik-baik saja" atau "tidak-baik-baik saja" dari para pakar domain - orang yang sangat penting dan tidak tergantikan pada tahap pemodelan bisnis saat membuat sistem.

Perhatikan juga bahwa langkah proses P5 terdiri dari dua bagian.

Dan kami menguraikan masing-masing bagian dan mempertimbangkan lebih detail (Gambar 3, Gambar 4), karena kegiatan yang dilakukan dalam kerangka langkah-langkah ini akan otomatis.

Gambar 3. Diagram aktivitas - detail (part1)

Gambar 4. Diagram aktivitas - detail (part2)

Tahap 2. Sorot apa yang bisa diotomatisasi

Langkah-langkah yang akan otomatis dalam diagram disorot dalam warna (lihat Gambar 3, Gambar 4).

Semuanya dilakukan oleh satu peserta dalam proses - petugas pesanan:

• Masukkan informasi tentang berat kacang dalam pernyataan;
• Memasukkan informasi tentang transfer kacang ke pernyataan;
• Ini memperbaiki fakta transformasi kacang menjadi kerang dan kernel;
• Masukkan informasi tentang kernel kacang dalam pernyataan;
• Masukkan informasi tentang kulit kenari dalam pernyataan.

Analisis pekerjaan dilakukan. Apa selanjutnya

Jadi, kami melakukan banyak pekerjaan persiapan: kami mengumpulkan informasi tentang proses yang akan kami otomatisasi; mulai merumuskan perjanjian pemodelan (sejauh ini hanya dalam hal menggunakan diagram Aktivitas); melakukan simulasi proses dan bahkan mendekomposisi beberapa langkahnya; mengidentifikasi langkah-langkah proses yang akan kami otomatisasi. Sekarang kita siap untuk melangkah ke langkah berikutnya dan mulai merancang fungsi sistem dan organisasi internalnya.

Seperti yang Anda tahu, teori tanpa praktik bukanlah apa-apa. Anda pasti harus mencoba "pemodelan" dengan tangan Anda sendiri, ini juga berguna untuk memahami pendekatan yang diusulkan. Misalnya, Anda dapat bekerja di lingkungan pemodelan Modelio [3]. Kami mendekomposisi hanya sebagian dari langkah-langkah diagram dari pandangan umum proses (lihat Gambar 2). Sebagai tugas praktis, mungkin disarankan untuk mengulangi semua diagram di lingkungan Modelio dan menguraikan langkah "Transfer / Penerimaan untuk Penyimpanan dan Pemrosesan".
Kami belum mempertimbangkan pekerjaan dalam lingkungan pemodelan tertentu, tetapi ini mungkin menjadi subjek dari artikel dan ulasan independen.

Pada bagian kedua artikel, kita akan menganalisis pemodelan dan teknik desain yang diperlukan dalam tahap 3-5, kita akan menggunakan diagram UML Use-case dan Class. Untuk dilanjutkan .