System sequence diagram (SSD)

System sequence diagram (SSD) adalah sistem yang di gunakan untuk mendeskripiskan aliran
data dari sistem .sistem ssd juga menggambrakan interaksi antara aktor dan sistem , SSD adalah
salah satu tipe dari intreaction diagaramn

Contoh pengaruh artefak UP

pada gambar use case ini dan adalah

kejadian sistem tersirat dalam input
untuk pembuatan SSD. Operasi SSD
(seperti enterItem) pada gilirannya dapat
dianalisis dalam kontrak operasi, dirinci
dalam Glosarium, dan sebagian besar
importantserve sebagai titik awal untuk
merancang objek yang berkolaborasi.

NextGen SSD

SSD menunjukkan, untuk rangkaian peristiwa tertentu dalam use case, aktor eksternal yang

berinteraksi langsung dengan sistem, sistem (sebagai kotak hitam), dan peristiwa sistem yang

dihasilkan oleh aktorWaktu berjalan ke bawah, dan urutan peristiwa harus mengikuti urutannya

dalam skenario.
SSD untuk skenario Proses Penjualan.

ini adalah untuk main success scenario dari skenario Proses Penjualan hanya melalui uang tunai.
gambar ini menunjukkan bahwa kasir menghasilkan gambaran sistem makeNewSale, enterItem,
endSale, dan makePayment.
Diagram Urutan Sistem

Use cases menggambarkan bagaimana aktor eksternal berinteraksi dengan sistem perangkat

lunak yang kami tertarik untuk membuat. Selama interaksi ini, seorang aktor membuat acara

sistem ke sistem, biasanya meminta beberapa operasi sistem untuk menangani acara tersebut.

Misalnya, ketika seorang kasir memasukkan ID suatu barang, kasir meminta sistem POS untuk

mencatat penjualan barang tersebut (peristiwa enterItem). Peristiwa itu memulai operasi pada

sistem. Teks use case menyiratkan peristiwa enterItem, dan SSD membuatnya konkret dan

eksplisit. UML mencakup diagram urutan sebagai notasi yang dapat menggambarkan interaksi

aktor dan operasi yang dilakukan oleh mereka. Diagram urutan sistem adalah gambar yang

menunjukkan, untuk satu skenario tertentu dari kasus penggunaan, peristiwa yang dihasilkan

oleh aktor eksternal, urutannya, dan peristiwa antar-sistem. Semua sistem diperlakukan sebagai

kotak hitam; penekanan diagram adalah peristiwa yang melintasi batas sistem dari aktor ke

sistem. kita harus merancang perangkat lunak untuk menangani peristiwa ini (dari mouse,

keyboard, sistem lain, ...) dan menjalankan respons. Pada dasarnya, sistem perangkat lunak

bereaksi terhadap tiga hal: 1) peristiwa eksternal dari aktor (manusia atau komputer), 2) peristiwa

waktu, dan 3) kesalahan atau pengecualian (yang seringkali dari sumber eksternal).

Oleh karena itu, penting untuk mengetahui apa, tepatnya, input eksternal dari peristiwa sistem.

Mereka adalah bagian penting dari analisis perilaku sistem.

Anda mungkin terbiasa dengan gagasan mengidentifikasi pesan yang masuk ke satu objek

perangkat lunak. Tetapi konsep ini berguna pada tingkat komponen yang lebih tinggi, termasuk

seluruh sistem yang dilihat (secara abstrak) sebagai satu hal atau objek.

Sebelum melanjutkan ke desain terperinci tentang cara kerja aplikasi perangkat lunak, ada

baiknya untuk menyelidiki dan mendefinisikan perilakunya sebagai "kotak hitam." Perilaku

sistem adalah deskripsi tentang apa yang dilakukan sistem, tanpa menjelaskan bagaimana
melakukannya. Salah satu bagian dari deskripsi itu adalah diagram urutan sistem. Bagian lain

termasuk kasus penggunaan dan kontrak operasi sistem (akan dibahas kemudian).

SSD menunjukkan peristiwa sistem untuk satu skenario use case, oleh karena itu dihasilkan dari
inspeksi use case
 Operation Contracts
Menggambarkan perilaku sistem terperinci dalam hal perubahan keadaan ke objek dalam
Model Domain, setelah operasi sistem telah dijalankan.didefinisikan untuk operasi sistem
operasi yang ditawarkan sistem dalam antarmuka publiknya untuk menangani peristiwa
sistem yang masuk.sistem dapat diidentifikasi dengan menemukan peristiwa sistem ini

Gambar:
Operasi sistem
menangani
kejadian sistem
input.

Seluruh
rangkaian
operasi sistem,
di semua kasus
penggunaan,
mendefinisikan
antarmuka
sistem public
UML - sistem secara
keseluruhan dapat diwakili oleh kelas.

Contoh Kontrak: enteritem

Kontrak C02: enteritem

Operation: enterltem (itemlD: ItemID, jumlah: integer)

Cross References: Use case: Proses Penjualan

Preconditions: Ada penjualan sedang berlangsung.

Postconditions: Sli instance SalesLineltem telah dibuat

(pembuatan instance).
sli dikaitkan dengan Penjualan saat ini (asosiasi
terbentuk).
sli.quantity menjadi kuantitas (modifikasi
atribut).
- sli dikaitkan dengan Spesifikasi Produk, berdasarkan
pada kecocokan itemlD (asosiasi terbentuk).
Bagian Kontrak - Templat
Deskripsi setiap bagian dalam kontrak ditunjukkan dalam skema berikut.
Operation: Nama operasi, dan parameter

Cross References: (opsional) Gunakan case operasi ini dapat terjadi di

dalam

Preconditions: Yang perlu diperhatikan asumsi tentang keadaan

sistem atau objek dalam Model Domain sebelum
pelaksanaan operasi. Ini tidak akan diuji dalam
logika operasi ini, dianggap benar, dan asumsi non-
sepele pembaca harus tahu dibuat.

Postconditions: Keadaan objek dalam Model Domain setelah

selesainya operasi. Dibahas secara rinci di bagian
berikut.

Postconditions
Postconditions adalah deklarasi tentang objek Model Domain yang benar ketika operasi telah
selesai
Perubahan status Model Domain meliputi:
1. Pembuatan instance dan penghapusan.
2. Modifikasi atribut.
3. Asosiasi terbentuk dan rusak
4. Keuntungan dari Postconditions

Menjelaskan perubahan keadaan yang diperlukan dari suatu operasi sistem tanpa harus
menjelaskan bagaimana mereka harus dicapai.
misal kondisi akhir:
Sli instance SalesLineltem telah dibuat (pembuatan instance).
sli dikaitkan dengan Penjualan saat ini (asosiasi terbentuk).
sli.quantity menjadi kuantitas (modifikasi atribut).
sli dikaitkan dengan Spesifikasi Produk, berdasarkan pada kecocokan itemlD
(asosiasi terbentuk).
Tidak ada komentar tentang bagaimana instance SalesLineltem dibuat, atau terkait
dengan Penjualan.
 Ekspresikan kondisi paska dalam bentuk lampau, untuk menekankan mereka adalah
deklarasi tentang perubahan keadaan di masa lalu.
Misalnya:
(Lebih baik) Suatu SalesLineltem telah dibuat.
(Lebih buruk) Buat SalesLineltem.
 Postconditions –enterItem Postconditions Discussion
Pembuatan Instans dan Penghapusan
Setelah itemLD dan jumlah item dimasukkan, objek baru SalesLineltem dibuat:

Sebuah SalesLineltem contoh sli diciptakan (misalnya penciptaan).

Modifikasi Atribut
Setelah itemlD dan kuantitas item telah dimasukkan oleh kasir,
yang kuantitas dari SalesLineltem  seharusnya menjadi sama dengan kuantitas parameter:

Sli.quantity menjadi kuantitas (modifikasi atribut).

Asosiasi Dibentuk dan Rusak

Setelah item dan jumlah item dimasukkan oleh kasir, SalesLineltem yang baru harus terkait
dengan Penjualannya, dan terkait dengan Spesifikasi Produknya :
·                  Sli dikaitkan dengan Penjualan saat ini (asosiasi terbentuk).
·                  Sli dikaitkan dengan Spesifikasi
Produk , berdasarkan kecocokan itemlD (asosiasi terbentuk).

·        Kapan Kontrak Berguna?

Use case adalah tempat penyimpanan utama dari persyaratan proyek.
Situasi di mana perincian dan kompleksitas perubahan status yang diperlukan sulit untuk
ditangkap dalam kasus penggunaan.
mis. sistem reservasi maskapai dan addNewReservation pengoperasian sistem .

Pedoman untuk membuat Kontrak

Identifikasi operasi sistem dari SSD.
Buat kontrak untuk operasi sistem yang rumit atau halus dalam hasilnya, atau yang tidak
jelas dalam kasus penggunaan
Jelaskan kondisi post, dengan menggunakan kategori berikut:
o         pembuatan instance dan penghapusan
o         modifikasi atribut
o         asosiasi terbentuk dan rusak

Sebutkan postconditions dalam bentuk lampau pasif dan deklaratif untuk menekankan
deklarasi perubahan negara alih-alih desain bagaimana hal itu akan dicapai. misal
(lebih baik) Suatu SalesLineltem telah dibuat.
(lebih buruk) Buat SalesLineltem.

Membangun memori antara objek yang ada atau yang baru dibuat dengan mendefinisikan
pembentukan asosiasi.misalnya:

 Tidak cukup jika instance SalesLineltem baru dibuat ketika operasi enterltem terjadi.

 Setelah operasi selesai, seharusnya benar bahwa instance yang baru dibuat dikaitkan
dengan Penjualan :he SalesLineltem dikaitkan dengan Sale (asosiasi yang dibentuk).
Contoh NextGen POS: Kontrak
Sistem Operasi Penjualan Proses

Kontrak COl: inakeNewSale

Operation: MakeNewSale ()

Cross References: Use case: Proses Penjualan

Preconditions: tidak ada

Postconditions: Penjualan instance s telah dibuat (pembuatan

instance).
s dikaitkan dengan Register (asosiasi terbentuk).
tribut s diinisialisasi.

Kontrak CO2: enterltem

Operation: enterltem (itemlD: ItemID, jumlah: integer)

Cross References: Gunakan Kasus: Proses Penjualan

Preconditions: Ada penjualan sedang berlangsung.

Postconditions: Sli instance SalesLineltem telah dibuat (pembuatan

instance).
s / i dikaitkan dengan Penjualan saat ini (asosiasi
disiksa).      
sli.quantity menjadi kuantitas (atribut moditication).      
sli dikaitkan dengan ProductSpecification, berdasarkan
kecocokan itemlD (asosiasi disiksa).

Kontrak C03: endSale

Operation: endSale ()

Cross References: Gunakan Kasus: Proses Penjualan

 Preconditions: Ada penjualan sedang berlangsung

Postconditions: Sale.isComplete menjadi true

(modifikasi atribut)

Kontrak C04: melakukan Pembayaran

Operation: makePayment (jumlah: Uang)

Cross References: Gunakan Kasus: Proses Penjualan

Preconditions: Ada penjualan sedang berlangsung.

Postconditions: Sebuah instance instance Pembayaran telah dibuat

(pembuatan instance).      
p.amount Tendered menjadi jumlah (atribut
moditication).      
p dikaitkan dengan Penjualan saat ini (asosiasi
disiksa).      
Penjualan saat ini dikaitkan dengan Store (asosiasi
tersiksa); (untuk menambahkannya ke log historis
penjualan lengkap)      

Kontrak, Operasi, dan UML

 UML secara resmi mendefinisikan operasi :
Operasi adalah spesifikasi transformasi atau kueri yang dapat dipanggil objek untuk
dieksekusi
 Sebuah metode (dalam UML) merupakan implementasi dari operasi.
 Operasi UML memiliki:
tanda tangan (nama dan parameter)
spesifikasi operasi - menjelaskan efek yang dihasilkan dengan menjalankan operasi
(postconditions). Kontrak yang diterapkan pada operasi di semua tingkat granularitas:
missal:
 operasi publik (atau antarmuka) dari suatu subsistem
 kelas abstrak

Operation Contracts Dalam UP
Fase
Inception -Tidak terlalu detail.
Elaborasi
 Sebagian besar kontrak ditulis selama elaborasi, ketika sebagian besar kasus penggunaan
ditulis.
Hanya tulis kontrak untuk operasi sistem yang paling rumit dan halus.

Operation Contract
 Contract CO1 : Admin Melakukan Login
Operation : Admin Melakukan Login()

Cross References : Use Cases : Cetak laporan

Precondition : -

Postcondition : Admin dapat memilih menu Utama

Contract CO2 : PilihMenuCetak Laporan

Operation : PilihMenuCetakLaporan ()

Cross References : Use Cases : Cetak laporan

Precondition : - Buka halaman khusus admin

Postcondition : - Sistem menampilkan menu Cetak laporan

Contract CO3 : Pilih menu Kategori

Operation : pilih menu kategori ()

Cross References : Use Cases : Mencetak Laporan

Precondition : - pilih menu cetak laporan

Postcondition : - Mencetak laporan

Contract CO4 : Cetak laporan

Operation : CetakLaporan ()
Cross References : Use Cases : MencetakLaporan

Precondition : - Menu kategori

Postcondition : - Mencetak laporan

Contract CO5 : Menerima Laporan

Operation : MenerimaLaporan()

Cross References : Use Cases : mencetaklaporan

Precondition : - Mencetaklaporan

Postcondition : - laporan dapat di akses pimpinan