Diagram urutan UML memodelkan arus logika dalam sistem Anda secara visual, memungkinkan Anda untuk mendokumentasikan dan memvalidasi logika Anda, dan biasanya digunakan untuk tujuan analisis dan perancangan. Diagram urutan adalah artefak UML yang paling populer untuk pemodelan dinamis, yang berfokus untuk mengidentifikasi perilaku di dalam sistem Anda. Teknik pemodelan dinamis lainnya meliputi activity diagraming. Diagram komunikasi Diagram waktu Dan diagram ikhtisar interaksi. Sequence diagram, bersama dengan diagram kelas dan model data fisik menurut saya merupakan model tingkat desain yang paling penting untuk pengembangan aplikasi bisnis modern. Diagram urutan biasanya digunakan untuk model: Skenario penggunaan. Skenario penggunaan adalah deskripsi tentang cara potensial sistem Anda digunakan. Logika skenario penggunaan mungkin merupakan bagian dari kasus penggunaan, mungkin kursus alternatif. Ini mungkin juga merupakan satu keseluruhan yang melewati kasus penggunaan, seperti logika yang dijelaskan oleh tindakan dasar atau sebagian dari tindakan dasar, ditambah satu atau lebih skenario alternatif. Logika skenario penggunaan juga bisa melewati logika yang terdapat dalam beberapa kasus penggunaan. Misalnya, seorang siswa mendaftar di universitas, dan kemudian segera mendaftar dalam tiga seminar. Logika metode. Diagram urutan dapat digunakan untuk mengeksplorasi logika operasi, fungsi, atau prosedur yang kompleks. Salah satu cara untuk memikirkan diagram urutan, khususnya diagram yang sangat rinci, adalah sebagai kode objek visual. Logika pelayanan. Sebuah layanan secara efektif merupakan metode tingkat tinggi, seringkali yang dapat dipanggil oleh beragam klien. Ini termasuk layanan web dan juga transaksi bisnis yang diterapkan oleh berbagai teknologi seperti CICSCOBOL atau CORBA-compliant object request calo (ORBs). Mari kita mulai dengan tiga contoh sederhana. Gambar 1 menggambarkan diagram urutan UML untuk mendaftar dalam kasus penggunaan Universitas, mengambil pendekatan tingkat sistem di mana interaksi antara aktor dan sistem ditunjukkan. Gambar 2 menggambarkan diagram urutan untuk logika rinci suatu layanan untuk menentukan apakah pemohon sudah menjadi siswa di universitas. Gambar 3 menunjukkan logika bagaimana cara mendaftar di seminar. Saya akan sering mengembangkan diagram urutan tingkat sistem dengan pemangku kepentingan untuk membantu memvisualisasikan dan memvalidasi logika skenario penggunaan. Ini juga membantu saya untuk mengidentifikasi metode metode yang signifikan, seperti memeriksa untuk melihat apakah pemohon sudah ada sebagai siswa, yang harus didukung oleh sistem saya. Gambar 1. Diagram urutan tingkat sistem. Alasan mengapa mereka memanggil diagram urutan harus jelas: sifat sekuensial logika ditunjukkan melalui urutan pesan (panah horizontal). Pesan pertama dimulai di sudut kiri atas, pesan berikutnya muncul tepat di bawah pesan itu, dan seterusnya. Kotak di bagian atas diagram mewakili penggolong atau contoh mereka, biasanya menggunakan kasus, objek, kelas, atau aktor. Karena Anda dapat mengirim pesan ke objek dan kelas, objek merespons pesan melalui seruan operasi dan kelas melakukannya melalui seruan operasi statis, masuk akal untuk menyertakan keduanya pada diagram urutan. Karena para aktor memulai dan mengambil bagian aktif dalam skenario penggunaan, mereka juga dapat disertakan dalam diagram urutan. Objek memiliki label dalam nama format UML standar: ClassName, di mana nama itu opsional (objek yang belum diberi nama pada diagram disebut objek anonim). Kelas memiliki label dalam format ClassName. Dan aktor memiliki nama dalam format Actor Name. Perhatikan bagaimana label objek digarisbawahi, kelas dan aktor tidak. Misalnya, pada Gambar 3. Anda melihat objek Siswa memiliki nama aStudent. Ini disebut objek bernama, sedangkan instance dari Seminar adalah objek anonim. Contoh Student diberi nama karena digunakan di beberapa tempat sebagai parameter dalam pesan, sedangkan contoh Seminar tidak perlu direferensikan di tempat lain dalam diagram dan karenanya bisa anonim. Pada Gambar 2 kelas Siswa mengirimkan pesan ke kelas PersistenceFramework (yang bisa saja diberi stereotip ltltinfrastructuregtgt tapi bukan untuk menjaga agar diagram tetap sederhana). Setiap pesan yang dikirim ke kelas diimplementasikan sebagai metode statis, lebih lanjut tentang ini nanti. Garis putus-putus yang tergantung di kotak itu disebut objek lifelines, yang mewakili rentang hidup objek selama skenario dimodelkan. Kotak panjang dan tipis pada garis hidup adalah kotak aktivasi, juga disebut kotak pemanggilan metode, yang mengindikasikan pemrosesan dilakukan oleh kelas objek target untuk memenuhi sebuah pesan. Saya hanya akan menggambar kotak aktivasi saat Im menggunakan alat yang mendukungnya secara native, seperti alat CASE yang canggih, dan saat saya ingin menjelajahi masalah kinerja. Kotak aktivasi terlalu canggung untuk menggambar di papan tulis atau dengan alat gambar sederhana sehingga tidak mudah mendukungnya. X di bagian bawah kotak aktivasi, contohnya disajikan pada Gambar 4. adalah konvensi UML untuk menunjukkan bahwa benda telah dihapus dari memori. Dalam bahasa seperti C di mana Anda perlu mengatur memori sendiri, Anda perlu meminta penghancur objek, biasanya memodelkan pesan dengan stereotip ltltdestroygtgt. Dalam bahasa seperti Java atau C dimana memori dikelola untuk Anda dan objek yang tidak lagi dibutuhkan secara otomatis dihapus dari memori, sesuatu yang sering disebut sebagai pengumpulan sampah, Anda tidak perlu memodelkan pesan. Saya biasanya tidak peduli dengan pemodelan objek kehancuran sama sekali dan malah akan mempercayai bahwa pemrogram, seringkali sendiri, akan menerapkan detail tingkat rendah seperti ini dengan tepat. Gambar 4 menyajikan diagram urutan UML yang rumit untuk tindakan dasar untuk mendaftar dalam kasus penggunaan Seminar. Ini adalah cara alternatif untuk memodelkan logika skenario penggunaan, alih-alih melakukannya di tingkat sistem seperti Gambar 1, Anda cukup terjun langsung ke pemodelan logika terperinci di tingkat objek. Saya mengambil pendekatan ini saat saya bekerja dengan pengembang yang berpengalaman diagrammers dan saya memiliki ruang kerja yang besar (baik papan tulis besar atau alat CASE yang terpasang di workstation dengan layar yang sangat besar dan kartu grafis yang bagus). Sebagian besar waktu saya menggambar diagram tingkat sistem terlebih dahulu dan kemudian membuat diagram kecil di sepanjang garis dari apa yang ditunjukkan pada Gambar 2 dan 3. Gambar 4. Dasar tindakan untuk mendaftar dalam kasus penggunaan Seminar. Pesan diindikasikan pada diagram urutan UML sebagai panah berlabel, bila sumber dan target pesan adalah objek atau kelas, labelnya adalah tanda tangan metode yang dipanggil sebagai tanggapan atas pesan tersebut. Namun, jika salah satu sumber atau targetnya adalah aktor manusia, maka pesan tersebut diberi label dengan teks singkat yang menjelaskan informasi yang dikomunikasikan. Sebagai contoh, pada Gambar 4, objek EnrollInSeminar mengirimkan pesan tersebut keEllibleToEnroll (theStudent) ke instance Seminar. Perhatikan bagaimana saya memasukkan nama metode dan nama parameter, jika ada, masuk ke dalamnya. Aktor Student memberikan informasi ke objek SecurityLogon melalui pesan berlabel nama dan nomor siswa (pesan benar-benar arent ini, sebenarnya mereka adalah interaksi pengguna). Nilai pengembalian secara opsional ditunjukkan dengan menggunakan panah putus-putus dengan label yang menunjukkan nilai balik. Sebagai contoh, nilai kembalian theStudent ditunjukkan kembali dari kelas Siswa sebagai hasil dari pemberian pesan, sedangkan tidak ada nilai pengembalian yang ditunjukkan sebagai hasil pengiriman pesan isEligibleToEnroll (theStudent) ke Seminar. Gaya saya bukan untuk menunjukkan nilai balik saat jelas apa yang dikembalikan, jadi saya tidak mengacaukan diagram urutan saya (seperti yang Anda lihat, diagram urutan menjadi rumit cukup cepat). Gambar 5 menunjukkan cara alternatif untuk menunjukkan nilai pengembalian menggunakan pesan format: returnValue untuk pesan, seperti yang dapat Anda lihat dengan isEligibleToEnroll (theStudent): false. Perhatikan penggunaan stereotip sepanjang diagram. Untuk kotak-kotak itu, saya menerapkan stereotip-stereotip yang ada pada masing-masing kelas, masing-masing kelas pengontrol, atau kelas antarmuka pengguna (UI). Saya juga menggunakan stereotip visual pada beberapa diagram sebagai contoh tongkat untuk aktor diagram ketahanan stereotip visual untuk objek kontrol, antarmuka, dan entitas dan drum untuk database. Stereotip juga digunakan pada pesan. Praktik umum pada diagram UML adalah untuk menunjukkan pesan penciptaan dan penghancuran dengan stereotip masing-masing dan masing-masing ltltcreategtgt dan ltltdestroygtgt. Misalnya, Anda melihat objek SecurityLogon dibuat dengan cara ini (sebenarnya, pesan ini kemungkinan akan dikirim ke kelas yang kemudian menghasilkan nilai pengembalian dari objek yang dibuat, jadi saya sedikit menipu). Objek ini kemudian menghancurkan dirinya sendiri dengan cara yang sama, mungkin saat jendela ditutup. Saya menggunakan catatan UML pada Gambar 4 pada dasarnya adalah teks bentuk bebas yang dapat ditempatkan pada diagram UML mana pun, untuk memberi judul pada diagram, yang menunjukkan judul dan identifiernya (seperti yang mungkin Anda perhatikan, saya memberi pengenal unik untuk semua Artefak yang ingin saya simpan). Catatan digambarkan sebagai selembar kertas dengan sudut kanan atas dilipat. Saya juga menggunakan catatan untuk menunjukkan pekerjaan masa depan yang perlu dilakukan, baik selama analisis atau desain, dalam diagram ini - pesan kualifikasi () kemungkinan mewakili rangkaian pesan yang dikirim ke objek siswa. Praktik UML yang umum adalah untuk memberi anchor catatan ke elemen model lain dengan garis putus-putus bila sesuai, dalam hal ini catatan dilekatkan pada pesan. Meskipun Gambar 4 memodelkan logika tindakan dasar untuk Pendaftaran dalam Seminar gunakan bagaimana Anda bisa memodelkan kursus alternatif Cara termudah untuk melakukannya adalah dengan membuat diagram urutan tunggal untuk setiap kursus alternatif, seperti yang Anda lihat digambarkan dalam Gambar 5. Diagram ini hanya memodelkan logika dari jalur alternatif, seperti yang dapat Anda ketahui dari penomoran langkah-langkah di sisi kiri diagram, dan catatan header untuk diagram menunjukkan bahwa ini adalah tindakan alternatif. Perhatikan juga bagaimana ID dari diagram ini mencakup bahwa ini adalah kursus alternatif C, namun aturan pemodelan lain yang saya anggap berguna selama ini. Mari pertimbangkan notasi diagram urutan lainnya. Gambar 5 mencakup pesan awal, Siswa memilih seminar. Yang ditunjukkan oleh lingkaran yang terisi. Hal ini dapat dengan mudah ditunjukkan melalui pemanggilan metode, mungkin masuk dalam (seminar). Gambar 6 menunjukkan cara lain untuk menunjukkan pembuatan objek yang mengirimkan pesan baru ke kelas. Weve benar-benar melihat tiga cara untuk mencapai ini, dua lainnya mengirim pesan dengan stereotip dan mungkin juga mengirim pesan ke sisi simbol classifier (misalnya pada Gambar 4, pesan masuk ke sisi EnrollInSeminar atau dalam Gambar 6 pesan masuk ke sisi StudentInfoPage Saran saya adalah memilih satu gaya dan menaatinya Angka 6 dan 7 masing-masing menggambarkan cara untuk menunjukkan logika perulangan Salah satu caranya adalah dengan menunjukkan bingkai dengan label loop dan sebuah batasan yang menunjukkan Apa yang sedang dilalui, seperti untuk setiap seminar pada Gambar 6. Pendekatan lain adalah dengan mendahului sebuah pesan yang akan dipanggil beberapa kali dengan tanda bintang, seperti yang Anda lihat pada Gambar 7 dengan masuknya daftar penggunaan dalam Use the Seminar in Seminar. Gambar 6 mencakup pesan asinkron, pesan ke printer sistem yang memiliki sebagian panah. Pesan asinkron adalah salah satu tempat pengirim tidak menunggu hasil pesan, melainkan memproses hasilnya kapan dan kapan Jika itu pernah kembali Sampai titik ini semua pesan lainnya telah sinkron, pesan dimana pengirim menunggu hasilnya sebelum melanjutkan. Biasanya mengirim pesan asinkron ke perangkat keras atau layanan perangkat lunak otonom seperti bus pesan. Metode pemodelan pencantuman kasus penggunaan yang digunakan pada Gambar 7 adalah sesuatu yang pertama kali saya usulkan dalam The Elements of UML Style walaupun saya tidak ragu lagi bahwa orang lain juga menggunakan pendekatan ini. Pada dasarnya saya menunjukkan kasus penggunaan sebagai gelembung di bagian atas diagram, sama seperti pengklasifikasi lainnya, dan menunjukkan pesan yang dikirim kepadanya dengan stereotip ltltincludegtgt. Hal ini konsisten dengan penggunaan diagram kasus dan praktik diagram urutan. Gambar 7 juga menarik karena menunjukkan bagaimana model logika kondisional. Dalam hal ini bingkai dengan label alt digunakan bersama dengan penjaga, dalam hal ini pemohon pada daftar kelayakan. Bingkai tersebut dipisahkan menjadi daerah yang dipisahkan oleh garis putus-putus. Dalam hal ini ada dua wilayah, satu untuk setiap alternatif, walaupun Anda dapat memiliki sebanyak mungkin daerah yang Anda butuhkan (untuk mendukung pernyataan setara visual dari sebuah pernyataan kasus). Setiap daerah membutuhkan penjaga. Visual Coding Dengan Diagram Urutan Sebelumnya saya menyatakan bahwa diagram urutan secara efektif merupakan bentuk pengkodean visual, atau mungkin cara lain untuk memahaminya adalah bahwa diagram urutan dapat digunakan untuk perancangan yang sangat rinci. Ketika saya mengembangkan diagram urutan Gambar 4, saya membuat beberapa keputusan yang berpotensi mempengaruhi model saya yang lain. Sebagai contoh, ketika saya memodelkan Langkah 10, saya membuat keputusan desain bahwa tampilan layar pembayaran juga menangani verifikasi oleh siswa bahwa biaya tersebut dapat diterima. Juga, saat saya membuat model Langkah 2 dan 3, saya menyadari bahwa siswa mungkin memiliki kata sandi untuk masuk ke sistem. Ketika Anda mengikuti praktik AM Partisipasi dan Model Pemangku Kepentingan Aktif dengan Orang Lain, mudah untuk mengetahui apakah gagasan seperti ini masuk akal karena yang perlu Anda lakukan hanyalah bertanya. Dalam kasus ini saya menemukan bahwa saya salah: kombinasi nama dan nomor siswa cukup unik untuk tujuan kita dan universitas tidak menginginkan kompleksitas manajemen kata kunci tambahan. Ini adalah keputusan menarik yang berpotensi dicatat sebagai aturan bisnis karena ini adalah kebijakan operasi universitas, yang mengindikasikan perlunya mengikuti praktik Iterate To Another Artifact dan mencatat peraturannya jika berminat untuk menyimpan catatan permanennya. . Bagaimana Menggambar Diagram Sequence Saya telah mencoba untuk menjelaskan kepada orang-orang bagaimana menggambar diagram urutan selama bertahun-tahun, dan apa yang saya temukan adalah bahwa orang-orang yang mendapatkannya sangat pandai berpikir secara logis dan jika mereka pandai menulis kode perangkat lunak. Urutan diagram sebenarnya adalah pengkodean visual, bahkan saat Anda memodelkan skenario penggunaan melalui diagram urutan tingkat sistem. Ketika saya membuat diagram urutan, matilah dengan mengidentifikasi lingkup dari apa yang saya coba modelkan, dan karena saya lebih memilih untuk mengikuti model latihan AM dalam Small increments III biasanya menangani skenario penggunaan kecil di tingkat sistem atau satu metode layanan pada objek yang terperinci. tingkat. Diagram seperti Gambar 4 terlalu rumit untuk berguna dalam pengalaman saya. Saya kemudian bekerja melalui logika dengan setidaknya satu orang lagi, meletakkan penggolong di atas saat saya membutuhkannya. Saya secara otomatis menambahkan objek lifelines tapi seperti yang saya tunjukkan sebelumnya biasanya tidak menginvestasikan waktu untuk menambahkan kotak aktivasi. Inti dari diagram ada dalam pesan, yang saya tambahkan ke diagram satu per satu saat saya mengerjakan logika. Saya jarang menunjukkan nilai kembali, malah Ill memberi pesan nama cerdas yang sering memperjelas apa yang sedang dikembalikan. Menarik untuk dicatat bahwa saat Anda menyusun diagram, Anda akan mengidentifikasi tanggung jawab baru untuk kelas dan objek, dan terkadang kelas baru sekalipun. Implikasinya adalah Anda mungkin ingin memperbarui model kelas Anda dengan tepat, pemodel tangkas akan mengikuti praktik Buat Beberapa Model secara Paralel. Sesuatu yang akan dilakukan alat CASE secara otomatis. Ingat, setiap pesan yang dikirim ke kelas memanggil operasi metode statis pada kelas itu setiap pesan yang dikirim ke sebuah objek memanggil operasi pada objek itu. Mengenai masalah gaya untuk diagram urutan, saya lebih suka menggambar pesan dari nilai ke kiri dan ke kanan dan mengembalikan nilai dari kanan ke kiri, meskipun itu tidak selalu bekerja dengan kelas benda yang kompleks. Saya membenarkan label pada pesan dan mengembalikan nilai, jadi mereka paling dekat dengan panah. Saya juga lebih memilih untuk melapisi diagram urutan: dari kiri ke kanan. Saya menunjukkan para aktor, lalu kelas pengontrol (es), dan kelas pengguna antarmuka (es), dan akhirnya kelas bisnis (es). Selama desain, Anda mungkin perlu menambahkan kelas sistem dan ketekunan, yang biasanya saya gunakan pada sisi paling kanan dari diagram urutan. Meletakkan diagram urutan Anda dengan cara ini sering membuat mereka lebih mudah dibaca dan juga memudahkan untuk menemukan masalah logika layering, seperti kelas antarmuka pengguna yang secara langsung mengakses kelas ketekunan. Menjaga Agile Hal terpenting yang dapat Anda lakukan adalah menjaga agar diagram Anda tetap sederhana, baik bijaksana maupun bijaksana. Saya akan membuat sketsa diagram urutan di papan tulis untuk memikirkan sesuatu, baik untuk memverifikasi logika dalam kasus penggunaan atau untuk merancang metode atau layanan. Saya jarang menyimpan diagram urutan karena saya menemukan nilai sebenarnya dari penciptaan mereka. Kesalahan umum adalah mencoba membuat rangkaian diagram urutan lengkap untuk sistem Anda. Saya telah melihat tim proyek menghabiskan beberapa bulan membuat beberapa diagram urutan untuk masing-masing kasus penggunaannya, satu untuk tindakan dasar dan satu untuk setiap kursus alternatif. Saran saya adalah hanya membuat diagram urutan bila Anda memiliki logika kompleks yang ingin Anda pikirkan jika logika itu mudah, diagram urutannya tidak akan menambah nilai apapun, mungkin Anda juga langsung menuju kode. Notasi yang digunakan dalam diagram ini, terutama gambar yang ditarik tangan, mungkin tidak sesuai dengan versi UML saat ini untuk satu atau beberapa alasan: Notasi tersebut mungkin berevolusi dari saat saya awalnya mengembangkan diagram. UML berevolusi dari waktu ke waktu, dan saya mungkin tidak menyimpan diagramnya. Saya mungkin salah dalam hal pertama. Meskipun diagram ini ditinjau secara menyeluruh untuk buku ini, dan telah ditinjau oleh ribuan orang secara online sejak saat itu, kesalahan mungkin telah berhasil melewati kami. Hanya manusia Saya mungkin telah memilih untuk menerapkan notasi dengan cara quotnon-standardquot. Seorang modeler tangkas lebih tertarik pada model terciptanya yang berkomunikasi secara efektif daripada menyesuaikan peraturan notasi yang ditetapkan oleh panitia. Mungkin tidak masalah, karena alat pemodelan yang Anda gunakan mungkin tidak akan sepenuhnya mendukung versi notasi UML saat ini dengan sempurna. Intinya adalah bahwa youre akan dibatasi oleh alat Anda pula. Jika Anda benar-benar memperhatikan nuansa notasi UML quotofficialquot, baca versi spesifikasi UML saat ini. Berbagi dengan teman-teman: Biarkan Kami Membantu Kami secara aktif bekerja sama dengan klien di seluruh dunia untuk memperbaiki praktik teknologi informasi mereka, biasanya dalam peran mentorcoach, tim lead, atau trainer. Penjelasan lengkap tentang apa yang kami lakukan, dan cara menghubungi kami, dapat ditemukan di Scott Ambler Associates. Bacaan yang Disarankan Buku ini, Pengiriman Agile yang Disiplin: Panduan Praktisi untuk Pengiriman Perangkat Lunak Agile dalam Perusahaan menggambarkan kerangka keputusan proses Ketenagakerjaan Discedlined Agile Delivery (DAD). Kerangka kerja DAD adalah pendekatan hibrida hibrida pertama yang berorientasi pada pembelajaran untuk pengiriman solusi TI. Ini memiliki siklus pengiriman nilai risiko, didorong oleh tujuan, adalah kesadaran perusahaan, dan memberikan dasar untuk menskalakan tangkas. Buku ini sangat penting bagi siapa saja yang ingin memahami bagaimana kerja tangkas dari ujung ke ujung dalam lingkungan perusahaan. Profesional data akan merasa menarik karena menunjukkan bagaimana pemodelan tangkas dan teknik database tangkas masuk ke dalam keseluruhan proses pengiriman solusi. Profesional perusahaan akan menganggapnya menarik karena secara eksplisit mempromosikan gagasan bahwa tim tangkas yang disiplin harus menyadari dan karenanya bekerja sama dengan tim perusahaan. Pengembang tangkas yang ada akan merasa menarik karena ini menunjukkan bagaimana memperluas strategi berbasis Scrum dan Kanban untuk memberikan proses penyampaian yang efisien dan efisien. Object Primer 3rd Edition: Model Agile Driven Development dengan UML 2 adalah buku referensi penting bagi pemodel tangkas, yang menjelaskan bagaimana mengembangkan 35 jenis model tangkas termasuk semua 13 diagram UML 2. Selanjutnya, buku ini menjelaskan teknik pemrograman dan pengujian mendasar untuk pengiriman solusi tangkas yang berhasil. Buku ini juga menunjukkan bagaimana untuk beralih dari model tangkas ke kode sumber, bagaimana berhasil pada teknik implementasi seperti refactoring dan test-driven development (TDD). Object Primer juga mencakup sebuah bab yang mengulas teknik pengembangan database penting (refactoring database, pemetaan objectrelational, analisis warisan dan pengkodean akses database) dari buku teknik Database Agile pemenang penghargaan. ConceptDraw Samples Proses bisnis Diagram UML Contoh Pengembangan Perangkat Lunak UML Cepat Diagram proses bisnis UML 2.4 dibuat dengan perangkat lunak ConceptDraw PRO dan perangkat lunak gambar vektor yang dilengkapi dengan solusi Rapid UML dari ConceptDraw Solution Park. ConceptDraw PRO menyediakan dokumen ekspor multipage vektor ke dalam beberapa format file: grafis vektor (SVG, EMF, EPS), grafis bitmap (PNG, JPEG, GIF, BMP, TIFF), dokumen web (HTML, PDF), presentasi PowerPoint (PPT ), Adobe Flash (SWF). Tutorial dan Solusi: Contoh 1: Diagram Aktivitas UML Contoh Activity Activity UML: Pengolahan Slip Deposit. Contoh ini dibuat dengan menggunakan software ConceptDraw PRO yang disempurnakan dengan solusi Rapid UML dari ConceptDraw Solution Park. Contoh 2: Diagram Komunikasi UML Diagram Komunikasi UML sampel. Contoh ini dibuat dengan menggunakan software ConceptDraw PRO yang disempurnakan dengan solusi Rapid UML dari ConceptDraw Solution Park. Contoh 3: Urutan Sequence UML Diagram Urutan UML. Contoh ini dibuat dengan menggunakan software ConceptDraw PRO yang disempurnakan dengan solusi Rapid UML dari ConceptDraw Solution Park. Contoh 4: UML Use Case Diagram Trading System UML Use Case Diagram contoh: Sistem Perdagangan. Contoh ini dibuat dengan menggunakan software ConceptDraw PRO yang disempurnakan dengan solusi Rapid UML dari ConceptDraw Solution Park. Semua sampel adalah hak cipta CS Odessas. Penggunaannya dicakup oleh Creative Commons Attribution Non-Komersial No Derivatives License. Diagram urutan Konten ini adalah bagian dari seri: UML dasar-dasar Nantikan konten tambahan dalam seri ini. Its Februari, dan sekarang Anda mungkin pernah membaca tentang, atau mendengar orang berbicara tentang, membuat perubahan ke UML 2.0 - spesifikasi baru untuk UML yang berisi sejumlah perbaikan. Mengingat pentingnya spesifikasi baru, kami mengubah dasar rangkaian artikel ini, juga, mengalihkan perhatian kami dari Spesifikasi OMGs UML 1.4 untuk Spesifikasi OMGs Adopted 2.0 Draft dari UML (a. k.a. UML 2). Saya benci untuk mengubah penekanan dari 1,4 menjadi 2,0 di tengah serangkaian artikel, namun UML 2.0 Draft Specification merupakan langkah maju yang penting, dan saya merasa perlu untuk menyebarkannya. Ada beberapa alasan mengapa OMG memperbaiki UML. Alasan utamanya adalah bahwa mereka menginginkan model UML mampu menghadirkan Model Driven Architecture (MDA), yang berarti bahwa UML harus berfungsi sebagai notasi yang lebih berorientasi pada model. Selain itu, notasi UML 1.x terkadang sulit diterapkan pada aplikasi yang lebih besar. Selanjutnya, elemen notasi perlu ditingkatkan agar diagram lebih mudah dibaca. (Misalnya, pemodelan arus logis dalam UML 1.x rumit dan terkadang tidak mungkin. Perubahan pada urutan diagram notasi yang ditetapkan dalam UML 2 telah membuat perbaikan besar dalam logika pemodelan dalam urutan.) Pelajari lebih lanjut. Kembangkan lebih banyak. Hubungkan lebih banyak. Salah satu fasilitas pengembangWorks Premium adalah akses ke lebih dari 500 buku dan video konferensi dari perpustakaan Safari. Beberapa judul yang mungkin menarik bagi Anda meliputi: Pola Arsitektur Aplikasi Perusahaan Arsitektur Aplikasi Java UML Distilasi: Panduan Singkat untuk Pemodelan Objek Standar Bahasa Konferensi Arsitektur Perangkat Lunak OReilly 2015 Kompilasi Video Lengkap Memeriksa semua yang ditawarkan oleh pengembangWorks Premium dan menjadi anggota hari ini. Perhatikan kata-kata dalam pernyataan saya di atas: Adopsi Spesifikasi Draf 2 UML. Memang benar bahwa spesifikasi masih dalam status draft, namun kuncinya adalah bahwa Draft Specification telah diadopsi oleh OMG, konsorsium yang tidak mengadopsi standar baru sampai menjadi solid. Akan ada beberapa perubahan pada spesifikasi sebelum UML 2 diadopsi sepenuhnya, namun perubahan ini harus minimal. Perubahan utama akan berada di internal UML - melibatkan fitur yang biasanya digunakan oleh perusahaan perangkat lunak yang menerapkan alat UML. Tujuan utama dari artikel ini adalah untuk melanjutkan fokus kami pada diagram UML yang penting bulan ini, kami melihat dari dekat diagram urutan. Harap perhatikan, sekali lagi, contoh yang diberikan di bawah didasarkan pada spesifikasi UML 2 yang baru. Tujuan diagram Diagram urutan digunakan terutama untuk menunjukkan interaksi antar objek dalam urutan urut bahwa interaksi tersebut terjadi. Sama seperti diagram kelas, pengembang biasanya menganggap diagram urutan dimaksudkan khusus untuk mereka. Namun, staf bisnis organisasi dapat menemukan diagram urutan yang berguna untuk mengkomunikasikan bagaimana bisnis saat ini bekerja dengan menunjukkan bagaimana berbagai objek bisnis berinteraksi. Selain mendokumentasikan sebuah organisasi urusan saat ini, diagram urutan tingkat bisnis dapat digunakan sebagai dokumen persyaratan untuk mengkomunikasikan persyaratan untuk implementasi sistem di masa depan. Selama fase persyaratan sebuah proyek, analis dapat menggunakan kasus ini ke tingkat berikutnya dengan memberikan tingkat penyempurnaan yang lebih formal. Bila itu terjadi, use case sering disempurnakan menjadi satu atau lebih sequence diagram. Staf teknis organisasi dapat menemukan diagram urutan yang berguna dalam mendokumentasikan bagaimana sistem masa depan harus berperilaku. Selama tahap perancangan, arsitek dan pengembang dapat menggunakan diagram tersebut untuk memaksa interaksi objek sistem, sehingga memudahkan keseluruhan perancangan sistem. Terapkan dengan penuh keyakinan Secara konsisten, kirimkan perangkat lunak berkualitas tinggi lebih cepat menggunakan layanan DevOps di IBM Bluemix. Mendaftar untuk percobaan awan Bluemix gratis. Dan mulai. Salah satu kegunaan utama dari diagram urutan adalah transisi dari persyaratan yang dinyatakan sebagai kasus penggunaan ke tingkat penyempitan berikutnya dan yang lebih formal. Use case sering disempurnakan menjadi satu atau lebih sequence diagram. Selain penggunaannya dalam merancang sistem baru, diagram urutan dapat digunakan untuk mendokumentasikan bagaimana objek dalam sistem yang ada (sebut saja warisan) saat ini berinteraksi. Dokumentasi ini sangat berguna saat mentransisikan sistem ke orang lain atau organisasi. Notasi Karena ini adalah artikel pertama dalam rangkaian diagram UML saya yang berbasis pada UML 2, pertama kita perlu membahas penambahan notasi pada diagram UML 2, yaitu elemen notasi yang disebut frame. Elemen frame digunakan sebagai dasar bagi banyak elemen diagram lainnya di UML 2, namun pada awalnya, kebanyakan orang akan menemukan elemen bingkai sebagai batas grafis diagram. Elemen bingkai menyediakan tempat yang konsisten untuk label diagram, sekaligus memberikan batas grafis untuk diagram. Elemen bingkai adalah opsional dalam diagram UML seperti yang dapat Anda lihat pada Gambar 1 dan 2, label diagram ditempatkan di sudut kiri atas pada apa yang disebut huruf namebox, semacam persegi panjang bertelinga anjing, dan diagram UML yang sebenarnya adalah Didefinisikan di dalam tubuh persegi panjang yang melingkar lebih besar. Gambar 1. Elemen UML 2 yang kosong Selain menyediakan batas visual, elemen frame juga memiliki kegunaan fungsional yang penting dalam diagram yang menggambarkan interaksi, seperti diagram urutan. Pada diagram urutan, pesan masuk dan keluar (a. k.a. interaksi) untuk suatu urutan dapat dimodelkan dengan menghubungkan pesan ke batas elemen bingkai (seperti yang terlihat pada Gambar 2). Ini akan dibahas lebih rinci di bagian Beyond the basics di bawah ini. Gambar 2. Diagram urutan yang memiliki pesan masuk dan keluar Perhatikan bahwa pada Gambar 2, diagram diagram diawali dengan huruf sd, untuk Sequence Diagram. Bila menggunakan elemen bingkai untuk melampirkan diagram, label diagram perlu mengikuti format: Spesifikasi UML menyediakan nilai teks spesifik untuk jenis diagram (mis., Diagram Urutan Sequence, Activity Activity Diagram, dan use case Use Case Diagram). Dasar-dasar Tujuan utama dari diagram urutan adalah untuk menentukan urutan peristiwa yang menghasilkan beberapa hasil yang diinginkan. Fokusnya kurang pada pesan itu sendiri dan lebih banyak lagi pada urutan pesan, namun kebanyakan diagram urutan akan mengkomunikasikan pesan apa yang dikirim antara objek sistem dan juga urutan kemunculannya. Diagram tersebut menyampaikan informasi ini di sepanjang dimensi horizontal dan vertikal: dimensi vertikal menunjukkan, top down, urutan waktu dari messagecalls saat terjadi, dan dimensi horizontal menunjukkan, kiri ke kanan, objek menunjukkan bahwa pesan dikirim. Saat menggambar diagram urutan, elemen notasi garis hidup ditempatkan di bagian atas diagram. Lifelines mewakili peran atau instance objek yang berpartisipasi dalam urutan yang dimodelkan. Catatan: Dalam sistem model penuh, objek (contoh kelas) juga akan dimodelkan pada diagram kelas sistem. Lifelines ditarik sebagai kotak dengan garis putus-putus turun dari bagian tengah tepi bawah (Gambar 3). Nama lifelines ditempatkan di dalam kotak. Gambar 3. Contoh kelas Siswa yang digunakan dalam garis hidup yang namanya adalah mahasiswa baru Standar UML untuk penamaan garis hidup mengikuti format: Pada contoh yang ditunjukkan pada Gambar 3, garis hidup mewakili sebuah instance dari Siswa kelas, yang contohnya Nama adalah mahasiswa baru Perhatikan bahwa, di sini, nama garis hidup digarisbawahi. Bila garis bawah digunakan, itu berarti garis hidup mewakili instance spesifik kelas dalam diagram urutan, dan bukan contoh khusus (misalnya peran). Dalam artikel mendatang perhatikan struktur pemodelan. Untuk saat ini, cukup amati bahwa diagram urutan dapat mencakup peran (seperti pembeli dan penjual) tanpa menentukan siapa yang memainkan peran tersebut (seperti Bill dan Fred). Hal ini memungkinkan penggunaan kembali diagram dalam konteks yang berbeda. Sederhananya, contoh nama dalam diagram urutan digarisbawahi peran nama tidak. Contoh lifeline kami pada Gambar 3 adalah objek bernama, namun tidak semua garis hidup mewakili objek bernama. Sebagai gantinya, jalur kehidupan dapat digunakan untuk mewakili contoh anonim atau tidak disebutkan namanya. Saat memodelkan contoh yang tidak disebutkan namanya pada diagram sekejap, nama garis hidup mengikuti pola yang sama dengan instance bernama tapi bukannya memberi nama instance, bagian dari nama lifeline itu dibiarkan kosong. Sekali lagi mengacu pada Gambar 3, jika garis hidup mewakili instance anonim kelas Siswa, jalur kehidupannya adalah: Siswa. Also, because sequence diagrams are used during the design phase of projects, it is completely legitimate to have an object whose type is unspecified: for example, freshman. The first message of a sequence diagram always starts at the top and is typically located on the left side of the diagram for readability. Subsequent messages are then added to the diagram slightly lower then the previous message. To show an object (i. e. lifeline) sending a message to another object, you draw a line to the receiving object with a solid arrowhead (if a synchronous call operation) or with a stick arrowhead (if an asynchronous signal). The messagemethod name is placed above the arrowed line. The message that is being sent to the receiving object represents an operationmethod that the receiving objects class implements. In the example in Figure 4, the analyst object makes a call to the system object which is an instance of the ReportingSystem class. The analyst object is calling the system objects getAvailableReports method. The system object then calls the getSecurityClearance method with the argument of userId on the secSystem object, which is of the class type SecuritySystem. Note: When reading this sequence diagram, assume that the analyst has already logged into the system. Figure 4. An example of messages being sent between objects Besides just showing message calls on the sequence diagram, the Figure 4 diagram includes return messages. These return messages are optional a return message is drawn as a dotted line with an open arrowhead back to the originating lifeline, and above this dotted line you place the return value from the operation. In Figure 4 the secSystem object returns userClearance to the system object when the getSecurityClearance method is called. The system object returns availableReports when the getAvailableReports method is called. Again, the return messages are an optional part of a sequence diagram. The use of return messages depends on the level of detailabstraction that is being modeled. Return messages are useful if finer detail is required otherwise, the invocation message is sufficient. I personally like to include return messages whenever a value will be returned, because I find the extra details make a sequence diagram easier to read. When modeling a sequence diagram, there will be times that an object will need to send a message to itself. When does an object call itself A purist would argue that an object should never send a message to itself. However, modeling an object sending a message to itself can be useful in some cases. For example, Figure 5 is an improved version of Figure 4. The Figure 5 version shows the system object calling its determineAvailableReports method. By showing the system sending itself the message determineAvailableReports, the model draws attention to the fact that this processing takes place in the system object. To draw an object calling itself, you draw a message as you would normally, but instead of connecting it to another object, you connect the message back to the object itself. Figure 5. The system object calling its determineAvailableReports method The example messages in Figure 5 show synchronous messages however, in sequence diagrams you can model asynchronous messages, too. An asynchronous message is drawn similar to a synchronous one, but the messages line is drawn with a stick arrowhead, as shown in Figure 6. Figure 6. A sequence diagram fragment showing an asynchronous message being sent to instance2 When modeling object interactions, there will be times when a condition must be met for a message to be sent to the object. Guards are used throughout UML diagrams to control flow. Here, I will discuss guards in both UML 1.x as well as UML 2.0. In UML 1.x, a guard could only be assigned to a single message. To draw a guard on a sequence diagram in UML 1.x, you placed the guard element above the message line being guarded and in front of the message name. Figure 7 shows a fragment of a sequence diagram with a guard on the message addStudent method. Figure 7. A segment of a UML 1.x sequence diagram in which the addStudent message has a guard In Figure 7, the guard is the text pastDueBalance 0. By having the guard on this message, the addStudent message will only be sent if the accounts receivable system returns a past due balance of zero. The notation of a guard is very simple the format is: Combined fragments (alternatives, options, and loops) In most sequence diagrams, however, the UML 1.x in-line guard is not sufficient to handle the logic required for a sequence being modeled. This lack of functionality was a problem in UML 1.x. UML 2 has addressed this problem by removing the in-line guard and adding a notation element called a Combined Fragment. A combined fragment is used to group sets of messages together to show conditional flow in a sequence diagram. The UML 2 specification identifies 11 interaction types for combined fragments. Three of the eleven will be covered here in The Basics section, two more types will be covered in the Beyond The Basics section, and the remaining six I will leave to be covered in another article. (Hey, this is an article, not a book. I want you to finish this piece in one day) Alternatives Alternatives are used to designate a mutually exclusive choice between two or more message sequences. Note: It is indeed possible for two or more guard conditions attached to different alternative operands to be true at the same time, but at most only one operand will actually occur at run time (which alternative wins in such cases is not defined by the UML standard). Alternatives allow the modeling of the classic if then else logic (e. g. if I buy three items, then I get 20 off my purchase else I get 10 off my purchase). As you will notice in Figure 8, an alternative combination fragment element is drawn using a frame. The word alt is placed inside the frames namebox. The larger rectangle is then divided into what UML 2 calls operands. Note: Although operands look a lot like lanes on a highway, I specifically did not call them lanes. Swim lanes are a UML notation used on activity diagrams. Please refer to The Rational Edges earlier article about Activity Diagrams . Operands are separated by a dashed line. Each operand is given a guard to test against, and this guard is placed towards the top left section of the operand on top of a lifeline. Note: Usually, the lifeline to which the guard is attached is the lifeline that owns the variable that is included in the guard expression. If an operands guard equates to true, then that operand is the operand to follow. Figure 8. A sequence diagram fragment that contains an alternative combination fragment As an example to show how an alternative combination fragment is read, Figure 8 shows the sequence starting at the top, with the bank object getting the checks amount and the accounts balance. At this point in the sequence the alternative combination fragment takes over. Because of the guard balance gt amount, if the accounts balance is greater than or equal to the amount, then the sequence continues with the bank object sending the addDebitTransaction and storePhotoOfCheck messages to the account object. However, if the balance is not greater than or equal to the amount, then the sequence proceeds with the bank object sending the addInsuffientFundFee and noteReturnedCheck message to the account object and the returnCheck message to itself. The second sequence is called when the balance is not greater than or equal to the amount because of the else guard. In alternative combination fragments, the else guard is not required and if an operand does not have an explicit guard on it, then the else guard is to be assumed. Alternative combination fragments are not limited to simple if then else tests. There can be as many alternative paths as are needed. If more alternatives are needed, all you must do is add an operand to the rectangle with that sequences guard and messages. The option combination fragment is used to model a sequence that, given a certain condition, will occur otherwise, the sequence does not occur. An option is used to model a simple if then statement (i. e. if there are fewer than five donuts on the shelf, then make two dozen more donuts). The option combination fragment notation is similar to the alternation combination fragment, except that it only has one operand and there never can be an else guard (it just does not make sense here). To draw an option combination you draw a frame. The text opt is placed inside the frames namebox, and in the frames content area the options guard is placed towards the top left corner on top of a lifeline. Then the options sequence of messages is placed in the remainder of the frames content area. These elements are illustrated in Figure 9. Figure 9. A sequence diagram fragment that includes an option combination fragment Reading an option combination fragment is easy. Figure 9 is a reworking of the sequence diagram fragment in Figure 7, but this time it uses an option combination fragment because more messages need to be sent if the students past due balance is equal to zero. According to the sequence diagram in Figure 9, if a students past due balance equals zero, then the addStudent, getCostOfClass, and chargeForClass messages are sent. If the students past due balance does not equal zero, then the sequence skips sending any of the messages in the option combination fragment. The example Figure 9 sequence diagram fragment includes a guard for the option however, the guard is not a required element. In high-level, abstract sequence diagrams you might not want to specify the condition of the option. You may simply want to indicate that the fragment is optional. Occasionally you will need to model a repetitive sequence. In UML 2, modeling a repeating sequence has been improved with the addition of the loop combination fragment. The loop combination fragment is very similar in appearance to the option combination fragment. You draw a frame, and in the frames namebox the text loop is placed. Inside the frames content area the loops guard is placed towards the top left corner, on top of a lifeline. Note: As with the option combination fragment, the loop combination fragment does not require that a guard condition be placed on it. Then the loops sequence of messages is placed in the remainder of the frames content area. In a loop, a guard can have two special conditions tested against in addition to the standard Boolean test. The special guard conditions are minimum iterations written as minint the number (e. g. minint 1) and maximum iterations written as maxint the number (e. g. maxint 5). With a minimum iterations guard, the loop must execute at least the number of times indicated, whereas with a maximum iterations guard the number of loop executions cannot exceed the number. Figure 10. An example sequence diagram with a loop combination fragment The loop shown in Figure 10 executes until the reportsEnu objects hasAnotherReport message returns false. The loop in this sequence diagram uses a Boolean test to verify if the loop sequence should be run. To read this diagram, you start at the top, as normal. When you get to the loop combination fragment a test is done to see if the value hasAnotherReport equals true. If the hasAnotherReport value equals true, then the sequence goes into the loop fragment. You can then follow the messages in the loop as you would normally in a sequence diagram Beyond the basics Ive covered the basics of the sequence diagram, which should allow you to model most of the interactions that will take place in a common system. The following section will cover more advanced notation elements that can be used in a sequence diagram. Referencing another sequence diagram When doing sequence diagrams, developers love to reuse existing sequence diagrams in their diagrams sequences. Note: It is possible to reuse a sequence diagram of any type (e. g. programming or business). I just find that developers like to functionally break down their diagrams more. Starting in UML 2, the Interaction Occurrence element was introduced. The addition of interaction occurrences is arguably the most important innovation in UML 2 interactions modeling. Interaction occurrences add the ability to compose primitive sequence diagrams into complex sequence diagrams. With these you can combine (reuse) the simpler sequences to produce more complex sequences. This means that you can abstract out a complete, and possibly complex, sequence as a single conceptual unit. An interaction occurrence element is drawn using a frame. The text ref is placed inside the frames namebox, and the name of the sequence diagram being referenced is placed inside the frames content area along with any parameters to the sequence diagram. The notation of the referenced sequence diagrams name follows the pattern of: 1. Retrieve Borrower Credit Report(ssn). borrowerCreditReport 2. Process Credit Card(name, number, expirationDate, amount. 100) In example 1, the syntax calls the sequence diagram called Retrieve Borrower Credit Report and passes it the parameter ssn. The Retreive Borrower Credit Report sequence returns the variable borrowerCreditReport. In example 2, the syntax calls the sequence diagram called Process Credit Card and passes it the parameters of name, number, expiration date, and amount. However, in example 2 the amount parameter will be a value of 100. And since example 2 does not have a return value labeled, the sequence does not return a value (presumably, the sequence being modeled does not need the return value). Figure 11. A sequence diagram that references two different sequence diagrams Figure 11 shows a sequence diagram that references the sequence diagrams Balance Lookup and Debit Account. The sequence starts at the top left, with the customer sending a message to the teller object. The teller object sends a message to the theirBank object. At that point, the Balance Lookup sequence diagram is called, with the accountNumber passed as a parameter. The Balance Lookup sequence diagram returns the balance variable. Then the option combination fragments guard condition is checked to verify the balance is greater then the amount variable. In cases where the balance is greater than the amount, the Debit Account sequence diagram is called, passing it the accountNumber and the amount as parameters. After that sequence is complete, the withdrawCash message returns cash to the customer. It is important to notice in Figure 11 that the lifeline of theirBank is hidden by the interaction occurrence Balance Lookup. Because the interaction occurrence hides the lifeline, that means that the theirBank lifeline is referenced in the Balance Lookup sequence diagram. In addition to hiding the lifeline in the interaction occurrence, UML 2 also specifies that the lifeline must have the same theirBank in its own Balance Lookup sequence. There will be times when you model sequence diagrams that an interaction occurrence will overlap lifelines that are not referenced in the interaction occurrence. In such cases the lifeline is shown as a normal lifeline and is not hidden by the overlapping interaction occurrence. In Figure 11, the sequence references the Balance Lookup sequence diagram. The Balance Lookup sequence diagram is shown in Figure 12. Because the example sequence has parameters and a return value, its label 8212located in the diagrams namebox8212follows a specific pattern: 1. SD Balance Lookup(Integer. accountNumber). Real 2. SD Available Reports(Financial Analyst. analyst). Reports Figure 12 illustrates example 1, in which the Balance Lookup sequence uses parameter accountNumber as a variable in the sequence, and the sequence diagram shows a Real object being returned. In cases such as this, where the sequence returns an object, the object being returned is given the instance name of the sequence diagram. Figure 12. A sequence diagram that takes the parameter of accountNumber and returns a Real object Figure 13 illustrates example 2, in which a sequence takes a parameter and returns an object. However, in Figure 13 the parameter is used in the sequences interaction. Figure 13. A sequence diagram that uses its parameter in its interaction and returns a Reports object The previous section showed how to reference another sequence diagram by passing information through parameters and return values. However, there is another way to pass information between sequence diagrams. Gates can be an easy way to model the passing of information between a sequence diagram and its context. A gate is merely a message that is illustrated with one end connected to the sequence diagrams frames edge and the other end connected to a lifeline. A reworking of Figures 11 and 12 using gates can be seen in Figures 14 and 15. The example diagram in Figure 15 has an entry gate called getBalance that takes the parameter of accountNumber. The getBalance message is an entry gate, because it is the arrowed line that is connected to the diagrams frame with the arrowhead connected to a lifeline. The sequence diagram also has an exit gate that returns the balance variable. The exit gate is known, because its a return message that is connected from a lifeline to the diagrams frame with the arrowhead connected to the frame. Figure 14. A reworking of Figure 11, using gates this time Figure 15. A reworking of Figure 12, using gates this time Combined fragments (break and parallel) In the basics section presented earlier in this paper, I covered the combined fragments known as alternative, option, and loop. These three combined fragments are the ones most people will use the most. However, there are two other combined fragments that a large share of people will find useful 128147 break and parallel. The break combined fragment is almost identical in every way to the option combined fragment, with two exceptions. First, a breaks frame has a namebox with the text break instead of option. Second, when a break combined fragments message is to be executed, the enclosing interactions remainder messages will not be executed because the sequence breaks out of the enclosing interaction. In this way the break combined fragment is much like the break keyword in a programming language like C or Java. Figure 16. A reworking of the sequence diagram fragment from Figure 8, with the fragment using a break instead of an alternative Breaks are most commonly used to model exception handling. Figure 16 is a reworking of Figure 8, but this time Figure 16 uses a break combination fragment because it treats the balance lt amount condition as an exception instead of as an alternative flow. To read Figure 16, you start at the top left corner of the sequence and read down. When the sequence gets to the return value balance, it checks to see if the balance is less than the amount. If the balance is not less than the amount, the next message sent is the addDebitTransaction message, and the sequence continues as normal. However, in cases where the balance is less than the amount, then the sequence enters the break combination fragment and its messages are sent. Once all the messages in the break combination have been sent, the sequence exits without sending any of the remaining messages (e. g. addDebitTransaction). An important thing to note about breaks is that they only cause the exiting of an enclosing interactions sequence and not necessarily the complete sequence depicted in the diagram. In cases where a break combination is part of an alternative or a loop, then only the alternative or loop is exited. Todays modern computer systems are advancing in complexity and at times perform concurrent tasks. When the processing time required to complete portions of a complex task is longer than desired, some systems handle parts of the processing in parallel. The parallel combination fragment element needs to be used when creating a sequence diagram that shows parallel processing activities. The parallel combination fragment is drawn using a frame, and you place the text par in the frames namebox. You then break up the frames content section into horizontal operands separated by a dashed line. Each operand in the frame represents a thread of execution done in parallel. Figure 17. A microwave is an example of an object that does two tasks in parallel While Figure 17 may not illustrate the best computer system example of an object doing activities in parallel, it offers an easy-to-understand example of a sequence with parallel activities. The sequence goes like this: A hungryPerson sends the cookFood message to the oven object. When the oven object receives that message, it sends two messages to itself at the same time (nukeFood and rotateFood). After both of these messages are done, the hungryPerson object is returned yummyFood from the oven object. Conclusion The sequence diagram is a good diagram to use to document a systems requirements and to flush out a systems design. The reason the sequence diagram is so useful is because it shows the interaction logic between the objects in the system in the time order that the interactions take place. Downloadable resources Related topicsSample UML Sequence Diagram The sequence diagram in figure 1 represents an elaboration for the Student Registers for Class use case in an automated student registration system. (Click here to see the diagram without the horizontal dotted guidelines.) Figure 1 - Automated Registration System sample sequence diagram The boxes at the top of the sequence diagram constitute the diagram header and represent the components or units of the system. Sequence diagram editor supports four types of header elements (see the full list of supported sequence diagram elements ): Actors - Actors represent a person or other external entity that interacts with the system. Objects - Objects are used to represent object instances in an object-oriented programming language such as Java or C. Units - Units are used to represent logical entities in the system such as components, servers, threads and tasks that may or may not be implemented using objects. They can also be used to distinguish objects from classes. Separators - Separators do not interact with the diagram but rather represent a boundary between header elements. Sequence diagram header elements can be grouped together (see group elements ) into components or subsystems to illustrate the logical layering of the system. In Figure 1, the web server components are grouped together into the Web Server group to indicate that these elements are part of the Web Server. Separator elements can be used to show boundaries between the components of the sequence diagram (such as the air interface between cell phone and base station, or the Internet in a distributed or web-based application). The body of the sequence diagram shows the interactions between the various units as they collaborate to accomplish a particular purpose. The dotted horizontal lines are called guidelines, which are typically used with their corresponding line numbers to refer to portions of the diagram in documentation or during design meetings ( Sequence Diagram Editor allows you to configure whether or not to display these guidelines andor line numbers in your sequence diagrams.) Messages are by far the most common elements and are used to model the interactions and interfaces between components. Sequence diagram editor supports six different types of message elements: Simple Messages - Simple messages can be used to represent interactions between components that are not direct method calls (could be IPC, remoting, http or web services) Asynchronous Messages - Asynchronous messages represent stimuli that can occur at any time based on external events (e. g. interruptssensors or user input) Call Messages - Call messages are usually reserved for method calls between objects in the same threadtask where the calling object waits for the return from the recipient before continuing Return Messages - Return messages indicate a response to a call message, although they can also be used with simple messages to represent requestresponse pairs. Create Messages - Create messages are used to represent the dynamic creation of an object instance. They can also be used to represent the creation of a thread or task. Destroy Messages - Destroy messages are used to represent the dynamic destruction of an object instance. They can also be used to represent the shutdown of a thread or task. Action elements can be used to represent an action or processing performed by a single entity without involving other units. In the sequence diagram example above, the Registration Page entity renders the page in line 16 using an action. State elements are useful for units representing a state machine to describe state transitions that occur as a result of sending a messages or some other event. Sates for different header elements can be configured to share the same guideline. Timer elements can be used to show the start, stop or expiration of a timer associated with a particular header element. They are used extensively in state machine design to handle error conditions when communicating with external systems. Diagram links represent a complex action performed by multiple header elements without showing all the details. For example, the quotuser loginquot box (line 7) in the sequence diagram typically involves interactions between the all the components. The details can be elaborated and shown in a separate sequence diagram with a link from the current diagram. Using diagram links to abstract details that are not specific or relevant to the current scenario reduces the size and clutter of the diagrams and enhances maintainability (used like a function call in a programming language.) Blocks are useful for representing simple alternation or looping constructs for a given header element. For example, in the sequence diagram of Figure 1 the student may not have to go through the login process if they are already logged into the system (line 6-7). If there are significant differences between the alternatives in the sequence diagram, using scenario elements like scenario start, scenario case, and scenario end rather than blocks may be more appropriate as illustrated in figure 2 (lines 22-29). You can always use additional sequence diagrams to describe different scenarios if it would be more clear. This sequence diagram shows the two alternative scenarios (course full found line 22, and No Service Found line 26) in the same diagram. Notice also that Sequence Diagram Editor automatically takes care of pagination by repeating the diagram title and header elements for each page. Documentation notes and Flow Notes are used throughout the sequence diagram to add additional descriptive text. These can be selectively hidden or displayed based on the desired detail level. Free Notes can also be used to add detail or annotations. Sequence Diagram Editor can also export diagrams in PDF (click here ) and RTF (click here ) formats. The PDF and RTF exports can optionally include documentation notes for the sequence diagram provided as a separate table at the end of the export. NOTE: while the exported RTF document tends to be large, opening this document with Microsoft Word and saving it as a Word document considerably reduces the size of the files (sometimes by a factor of 20 or more.) Click here for the corresponding Word document.
No comments:
Post a Comment