Buku ini menerangkan satu kaedah untuk menulis sebahagian pernyataan masalah iaitu kaedah use case.
Apa ini? Ini ialah perihalan senario interaksi pengguna dengan sistem (atau dengan perniagaan). Dalam kes ini, sistem bertindak sebagai kotak hitam (dan ini memungkinkan untuk membahagikan tugas reka bentuk yang kompleks kepada mereka bentuk interaksi dan memastikan interaksi ini). Pada masa yang sama, piawaian notasi diperkenalkan, yang memastikan kemudahan membaca, termasuk untuk bukan peserta, dan membenarkan beberapa semakan untuk kesempurnaan dan pematuhan dengan matlamat pihak berkepentingan.
Gunakan contoh kes
Bagaimana rupa senario itu, menggunakan contoh kebenaran di tapak melalui e-mel:
(Sistem) Log masuk ke laman web untuk mengakses akaun peribadi anda. ~~ (paras laut)
Konteks: Pelanggan yang tidak dibenarkan log masuk ke tapak supaya tapak itu mengenalinya dan menunjukkan maklumat peribadi untuknya: sejarah penyemakan imbas, sejarah pembelian, bilangan mata bonus semasa, dsb., menggunakan e-mel sebagai log masuk.
Tahap: matlamat pengguna
Watak utama: pelanggan (pelawat kedai dalam talian kami)
Skop: Interaksi pelanggan dengan tapak web kedai dalam talian
Pihak berkepentingan dan kepentingan:
- pemasar mahu bilangan maksimum pelawat tapak dikenal pasti untuk liputan yang lebih luas bagi mel peribadi,
- pakar keselamatan ingin memastikan bahawa tiada kes akses tanpa kebenaran kepada data peribadi pelawat, termasuk percubaan untuk meneka kata laluan untuk satu akaun atau mencari akaun dengan kata laluan yang lemah,
- penyerang ingin mendapatkan akses kepada bonus mangsa,
- pesaing ingin meninggalkan ulasan negatif pada produk,
- Botnet ingin mendapatkan pangkalan pelanggan kedai dan menggunakan serangan untuk menjadikan tapak itu tidak boleh beroperasi.
Prasyarat: pelawat mestilah tidak dibenarkan.
Jaminan minimum: pelawat akan mengetahui sama ada percubaan kebenaran itu berjaya atau tidak.
Jaminan kejayaan: pelawat diberi kuasa.
Senario utama:
- Pelanggan memulakan kebenaran.
- Sistem mengesahkan bahawa pelanggan tidak dibenarkan dan tidak melebihi bilangan percubaan kebenaran yang tidak berjaya dari sesi tertentu (mencari kata laluan yang lemah untuk berbilang akaun) mengikut "Peraturan Keselamatan No. 23".
- Sistem meningkatkan kaunter untuk bilangan percubaan kebenaran.
- Sistem memaparkan borang kebenaran kepada pelanggan.
- Pelanggan memasukkan e-mel dan kata laluannya.
- Sistem mengesahkan kehadiran pelanggan dengan e-mel sedemikian dalam sistem dan kata laluan sepadan dan bilangan percubaan log masuk ke akaun ini tidak melebihi mengikut "Peraturan Keselamatan No. 24".
- Sistem membenarkan pelanggan, menambah sejarah penyemakan imbas dan bakul sesi ini dengan sesi terakhir akaun pelanggan ini.
- Sistem memaparkan mesej kejayaan kebenaran dan bergerak ke langkah skrip dari mana pelanggan telah diganggu untuk mendapatkan kebenaran. Dalam kes ini, data pada halaman dimuat semula dengan mengambil kira data akaun peribadi.
Sambungan:
2.a. Pelanggan telah diberi kuasa:
2.a.1. Sistem memberitahu pelanggan tentang fakta kebenaran yang dilakukan sebelum ini dan menawarkan sama ada mengganggu skrip atau pergi ke langkah 4, dan jika langkah 6 berjaya diselesaikan, maka langkah 7 dilakukan dengan penjelasan:
2.a.7. Sistem menyahaktifkan pelanggan di bawah akaun lama, membenarkan pelanggan di bawah akaun baharu, manakala sejarah penyemakan imbas dan troli sesi interaksi ini kekal dalam akaun lama dan tidak dipindahkan ke akaun baharu. Seterusnya, pergi ke langkah 8.
2.b Bilangan percubaan kebenaran telah melebihi ambang mengikut βPeraturan Keselamatan No. 23β:
2.b.1 Pergi ke langkah 4, captcha juga dipaparkan pada borang kebenaran
2.b.6 Sistem mengesahkan kemasukan captcha yang betul
2.b.6.1 Captcha dimasukkan dengan salah:
2.b.6.1.1. sistem meningkatkan kaunter percubaan kebenaran yang tidak berjaya untuk akaun ini juga
2.b.6.1.2. sistem memaparkan mesej kegagalan dan kembali ke langkah 2
6.a. Tiada akaun dengan e-mel ini ditemui:
6.a.1 Sistem memaparkan mesej tentang kegagalan dan menawarkan pilihan sama ada pergi ke langkah 2 atau pergi ke senario "Pendaftaran Pengguna" dan menyimpan e-mel yang dimasukkan,
6.b. Kata laluan untuk akaun dengan e-mel ini tidak sepadan dengan yang dimasukkan:
6.b.1 Sistem meningkatkan kaunter percubaan log masuk yang tidak berjaya ke akaun ini.
6.b.2 Sistem memaparkan mesej tentang kegagalan dan menawarkan pilihan sama ada pergi ke senario "Pemulihan Kata Laluan" atau pergi ke langkah 2.
6.c: Kaunter percubaan log masuk untuk akaun ini telah melebihi ambang untuk "Peraturan Keselamatan No. 24."
6.c.1 Sistem memaparkan mesej tentang penyekatan log masuk akaun selama X minit dan meneruskan ke langkah 2.
Apa yang hebat
Semak kesempurnaan dan pematuhan matlamat, iaitu, anda boleh memberikan keperluan kepada penganalisis lain untuk pengesahan, membuat lebih sedikit kesilapan pada peringkat perumusan masalah.
Bekerja dengan sistem jenis kotak hitam membolehkan anda memisahkan pembangunan dan penyelarasan dengan pelanggan tentang perkara yang akan diautomatikkan daripada kaedah pelaksanaan.
Ia adalah sebahagian daripada laluan penganalisis, salah satu bahagian utama kebolehgunaan. Senario pengguna mentakrifkan laluan utama pergerakannya, yang sangat mengurangkan kebebasan memilih untuk pereka bentuk dan pelanggan serta membantu meningkatkan kelajuan pembangunan reka bentuk.
Saya sangat berpuas hati dengan tempat dalam perihalan di mana pengecualian untuk setiap langkah interaksi dikenal pasti. Sistem IT yang lengkap mesti menyediakan beberapa jenis pengendalian pengecualian, beberapa secara manual, beberapa secara automatik (seperti dalam contoh di atas).
Pengalaman menunjukkan bahawa pengendalian pengecualian yang tidak difikirkan dengan mudah boleh mengubah sistem menjadi sistem yang amat menyusahkan. Saya masih ingat kisah ketika zaman Soviet, untuk mendapatkan keputusan, anda perlu mendapatkan beberapa kelulusan daripada perkhidmatan yang berbeza, dan betapa peritnya apabila perkhidmatan terakhir berkata - tetapi permohonan anda adalah dalam nama yang salah atau beberapa kesilapan lain dalam tanda baca, buat semula segala-galanya dan selaraskan semula segala-galanya.
Saya sering menemui situasi di mana logik pengendalian sistem yang tidak difikirkan untuk pengecualian memerlukan kerja semula sistem yang ketara. Oleh sebab itu, bahagian terbesar kerja penganalisis dibelanjakan untuk pengendalian pengecualian.
Notasi teks, berbanding gambar rajah, membolehkan lebih banyak pengecualian dikenal pasti dan diliputi.
Tambahan kepada kaedah dari amalan
Kes penggunaan bukanlah bahagian penyataan yang diutamakan secara bebas, tidak seperti cerita pengguna.
Dalam senario di atas, pertimbangkan pengecualian β6.a. Tiada akaun dengan e-mel ini ditemui.β dan langkah seterusnya "6.a.1 Sistem memaparkan mesej kegagalan dan meneruskan ke langkah 2." Apakah perkara negatif yang ditinggalkan di sebalik tabir? Bagi pelanggan, sebarang pulangan adalah sama dengan fakta bahawa semua kerja yang dilakukannya memasukkan data dibuang ke tapak pelupusan sampah. (Ia hanya tidak kelihatan dalam skrip!) Apa yang boleh dilakukan? Bina semula skrip supaya ini tidak berlaku. Adakah mungkin untuk melakukan ini? Anda boleh - sebagai contoh, lihat skrip kebenaran Google.
Pengoptimuman senario
Buku ini bercakap tentang pemformalkan, tetapi bercakap sedikit tentang kaedah untuk mengoptimumkan senario sedemikian.
Tetapi adalah mungkin untuk mengukuhkan kaedah dengan mengoptimumkan senario, dan kaedah pemformalan kes penggunaan membolehkan ini dilakukan. Secara khusus, anda perlu memikirkan setiap pengecualian yang berlaku, menentukan punca dan membina semula skrip untuk menyingkirkan pengecualian atau meminimumkan perjalanan pelanggan.
Apabila membuat pesanan dari kedai dalam talian, anda mesti memasuki bandar penghantaran. Ia mungkin ternyata bahawa kedai tidak dapat menghantar barang ke bandar yang dipilih oleh pelanggan kerana ia tidak menghantar ke sana, disebabkan oleh sekatan saiz, atau kerana kekurangan barang di gudang yang sepadan.
Jika kita hanya menerangkan senario interaksi pada peringkat pendaftaran, kita boleh menulis "maklumkan kepada pelanggan bahawa penghantaran adalah mustahil dan tawarkan untuk menukar bandar atau kandungan troli" (dan ramai penganalisis baru berhenti di sana). Tetapi jika terdapat banyak kes sedemikian, maka senario itu boleh dioptimumkan.
Perkara pertama yang perlu anda lakukan ialah membenarkan anda memilih hanya bandar yang boleh kami hantar. Bila nak buat ni? Sebelum memilih produk di laman web (pengesan automatik bandar melalui IP dengan penjelasan).
Kedua, kita perlu memberi pilihan hanya barangan yang boleh kita hantar kepada pelanggan. Bila nak buat ni? Pada masa pemilihan - pada jubin produk dan kad produk.
Kedua-dua perubahan ini pergi jauh ke arah menghapuskan pengecualian ini.
Keperluan untuk ukuran dan metrik
Apabila mempertimbangkan tugas meminimumkan pengendalian pengecualian, anda boleh menetapkan tugas pelaporan (kes penggunaan tidak diterangkan). Berapa banyak pengecualian yang ada, dalam kes apa ia berlaku, serta berapa banyak senario masuk berjaya diluluskan.
Tapi sayangnya. Pengalaman telah menunjukkan bahawa keperluan pelaporan untuk senario dalam bentuk ini tidak mencukupi; adalah perlu untuk mempertimbangkan keperluan pelaporan untuk proses yang diterangkan terutamanya bukan dalam bentuk kes penggunaan.
Akses kepada Kebolehgunaan
Dalam amalan kami, kami telah mengembangkan borang perihalan kes penggunaan dengan perihalan atribut khusus entiti dan data untuk pelanggan membuat keputusan, yang meningkatkan kebolehgunaan seterusnya.
Untuk reka bentuk kebolehgunaan, kami menambah bahagian input - paparan data.
Dalam senario dengan kebenaran, ini adalah hakikat bahawa pelanggan diberi kuasa dalam sistem. Jika pelanggan diberi pra-kebenaran, kemudian paparkan amaran tentang menukar sejarah navigasi dan troli ke akaun baharu selepas kebenaran berjaya.
Secara umum, ini adalah paparan maklumat yang diperlukan untuk pelanggan supaya dia boleh membuat keputusan tentang tindakan selanjutnya mengikut senario (anda boleh bertanya sama ada data ini mencukupi untuk pelanggan, apa lagi yang diperlukan, maklumat apa yang dilakukan klien perlu membuat keputusan).
Ia juga bernilai membahagikan maklumat yang dimasukkan ke dalam medan input jika ia diproses secara berasingan dan dengan pembentukan pengecualian yang berbeza.
Dalam contoh dengan kebenaran pelanggan, jika anda memisahkan maklumat yang dimasukkan ke dalam log masuk dan kata laluan, maka perlu menukar skrip kebenaran untuk menyerlahkan peringkat memasukkan log masuk berasingan dan kata laluan berasingan (dan ini dilakukan di Yandex, Google, tetapi tidak dilakukan di kebanyakan kedai dalam talian).
Mencapai transformasi data yang diperlukan
Anda juga boleh mengekstrak keperluan untuk algoritma penukaran data daripada skrip.
ΠΡΠΈΠΌΠ΅ΡΡ:
- Untuk membuat keputusan untuk membeli produk di kedai dalam talian, pelanggan perlu mengetahui pada kad produk kemungkinan, kos, masa penghantaran ke bandarnya produk ini (yang dikira oleh algoritma berdasarkan ketersediaan produk dalam gudang dan parameter rantaian bekalan).
- Apabila memasukkan frasa ke dalam baris carian, pelanggan ditunjukkan cadangan carian mengikut algoritma (yang dihasilkan oleh algoritma...).
Dalam jumlah
Secara umum, selepas membaca buku itu, malangnya, tidak jelas bagaimana untuk pergi dari penganalisis kepada masalah perniagaan kepada spesifikasi teknikal rasmi untuk pemaju. Buku ini hanya memberitahu sebahagian daripada proses, dengan langkah input tidak jelas dan langkah seterusnya tidak jelas. Kes penggunaan itu sendiri selalunya bukan pernyataan lengkap untuk pembangun.
Walau bagaimanapun, ini adalah cara yang sangat baik untuk memformalkan dan memproses senario interaksi antara objek dan subjek, apabila interaksi menyebabkan perubahan dalam sesuatu subjek. Ia adalah salah satu daripada beberapa kaedah penulisan yang membenarkan keperluan yang boleh disahkan dengan titik carian pengecualian yang jelas.
Buku ini mesti dibaca oleh penganalisis untuk mula menulis drama yang boleh diuji.
Sumber: www.habr.com