Kepura-puraan kelas model UML

masukkan deskripsi gambar di sini

Saya mencoba memodelkan dengan UML masalah yang saya alami, yaitu struktur penukar tertentu.

Saya memiliki kelas pusat, Matrix, yang memiliki beberapa sirkuit yang mengalir melaluinya, kelas Circuit. Matriks ini adalah tumpukan lintasan (kelas Passage), yang di dalamnya beredar satu atau lebih sirkuit. Satu rangkaian juga dapat mengalirkan beberapa lintasan.

Katakanlah objek bagian diberi nama "A", "B" dan "C", matriksnya akan terlihat seperti : ABCCABA...

Saya akan menggunakan referensi, seperti array pointer

Bagaimana cara memodelkan pola penumpukan itu di UML?

Lalu, saya ingin mengatakan bahwa A berisi 2 objek sirkuit "1" dan "2", B berisi "2" dan C berisi "3".

Bantu saya mencari tahu cara melakukan ini


person renaud E    schedule 16.02.2015    source sumber
comment
Ini mungkin masalah bahasa, tetapi kelas tidak mengalir dan Anda tidak dapat menumpuknya. Apakah Anda ingin mengetahui cara memodelkan kelas yang mewakili matriks? Dan satu lagi untuk memodelkan tumpukan?   -  person qwerty_so    schedule 16.02.2015
comment
Oh begitu, mungkin ada kekeliruan dalam penggunaan flow dan stack. Saya sebenarnya tidak ingin menumpuk atau membuat mengalir kelas itu sendiri, melainkan objeknya. Dan yang paling penting, saya ingin memahami jenis asosiasi apa yang harus saya gunakan agar struktur ini berfungsi   -  person renaud E    schedule 16.02.2015


Jawaban (2)


Pertanyaan Anda masih dalam bentuk yang memungkinkan (terlalu) banyak jawaban, tapi saya akan mencoba cara ini.

  • Untuk setiap langkah di bawah ini, libatkan pemangku kepentingan yang tepat untuk mengambil bagian dalam perancangan.
  • Make up your mind what you actually want to do. What is the purpose of the matrix/stack (your question does not provide background).
    • A good way is to create use cases to describe the goals of your system
  • Asalkan Anda tahu apa tujuan sistem tersebut, buatlah domain menggunakan diagram kelas. Diagram kelas di atas terlihat oke tetapi tanpa konteks saya tidak tahu apakah itu benar atau salah.
  • Once you got that structural model you can start designing functionality. The best approach is this:
    • Create a collaboration for each of your use cases (also known as use case realizations; they have a realization towards the use case).
    • Di dalam setiap kolaborasi, buatlah diagram urutan dan tempatkan instance dari kelas-kelas tersebut di dalamnya yang seharusnya mengambil bagian dalam kasus penggunaan khusus ini
    • Sekarang mulailah memikirkan bagaimana instance ini perlu berkomunikasi untuk melakukan tugas yang diinginkan
    • Gambarkan pesan untuk menunjukkan komunikasi dan buat metode di kelas yang sesuai (beberapa alat mendukung ini dalam satu langkah)
    • Tinjau komunikasi dan model domain

Secara kasar ini adalah langkah desain utama. Seperti yang Anda lihat, saya tidak memberikan jawaban spesifik untuk masalah yang mungkin Anda pikirkan. Hanya karena itu tidak cukup spesifik.

Beri seseorang seekor ikan, maka ia akan mendapat makan untuk sehari. Ajari dia memancing dan dia akan makan seumur hidupnya.

person qwerty_so    schedule 16.02.2015
comment
Saya telah mencari semacam pedoman selama beberapa waktu sekarang, saya baru saja memberikannya kepada saya. Terima kasih. Saya rasa saya akan memikirkannya, dan jika masih belum jelas, saya akan kembali untuk meminta bantuan jika tidak masalah. Terima kasih ! - person renaud E; 16.02.2015
comment
Tidak masalah. Anda mungkin memilih jika itu membantu :-) UML adalah sebuah bahasa. Dan Anda hanya bisa belajar dengan mempraktikkannya. Pergi saja ke UMLand di mana semua orang berbicara UML sehingga Anda terpaksa belajar - atau kelaparan ;-) Anda dipersilakan untuk mengajukan pertanyaan lebih lanjut jika Anda mengalami kebuntuan sekali lagi. - person qwerty_so; 16.02.2015
comment
Saya tahu UML cukup baik, dan jika saya tidak memiliki pengetahuan lain, saya MASIH kelaparan. :) - person BobRodes; 17.02.2015
comment
@ThomasKilian: Saya selalu merekomendasikan diagram aktivitas (tempat Anda berkolaborasi) untuk setiap kasus penggunaan, dengan diagram urutan untuk masing-masing skenario dalam kasus penggunaan. - person BobRodes; 17.02.2015
comment
@BobRodes: AD masuk ke UC untuk menjelaskan apa yang terjadi. Anda dapat menggunakan AD sebagai alternatif SD jika diperlukan (ada hubungan 1:1). AD lebih baik dalam gambaran struktural sementara SD tepat waktu. - person qwerty_so; 17.02.2015
comment
@ThomasKilian: Saya tidak yakin sepenuhnya setuju bahwa ada hubungan 1:1 antara AD dan SD. Mungkin saya tidak mengerti maksud Anda? Saya tidak melihat cara mudah untuk memodelkan perilaku thread paralel di SD seperti yang dilakukan fork dan join dengan baik di AD. Saya juga melihat SD memiliki level yang sedikit lebih rendah daripada AD; sulit untuk memodelkan aliran interaksi antara dua objek pada tingkat pemanggilan metode dalam AD. - person BobRodes; 17.02.2015
comment
Fakta bahwa ada hubungan 1:1 tidak berarti konversinya mudah. Juga fakta bahwa Anda bisa melakukannya bukan berarti Anda harus melakukannya. Fokus keduanya berbeda seperti yang saya nyatakan. Jadi, Anda harus menggunakan salah satu tempat yang menurut Anda fokusnya paling dibutuhkan. Kami mungkin memulai diskusi di LinkedIn linkedin.com/ - person qwerty_so; 17.02.2015

Struktur konkrit dari relasi instance akan ditampilkan dalam Diagram Objek.

Namun diagram ini tidak sekuat dan seuniversal diagram kelas. Jadi, kemungkinan besar, Anda harus membuat diagram sendiri.

Lihat juga Diagram Struktur Komposit

person Gangnus    schedule 16.02.2015