Bab 6 Rekayasa Sistem
Tujuan Pembelajaran Umum Mendeskripsikan Perangkat Lunak Praktis Tujuan Pembelajaran Khusus Mampu Mengidentifikasikan Rekayasa Sistem
Rekayasa Sistem Komputer (Computer system engineering) terdiri atas 2 bagian, yaitu : Hardware engineering Software engineering
Setiap disiplin ini berusaha menunjukkan pengembangan sistem berbasis komputer tehnik engineering. Untuk hardware komputer telah sedemikian maju dan relatif jenuh. Sebaliknya software komputer mulai berkembang, dan saat ini menggantikan peranan hardware sebagai elemen sistem yang sulit direncanakan, sedikit kemungkinan untuk berhasil dengan biaya rendah dan waktu yang cepat, serta paling sukar untuk dikelola. Apa Sistem itu ? Sistem adalah sekumpulan elemen yang saling berinteraksi untuk mencapai suatu tujuan. Sedangkan Computer Based System diorganisir untuk mendapatkan beberapa metode, prosedur atau pengontrolan dengan cara mengelola informasi. Elemen-elemen dari sistem berbasis komputer adalah : 1. Software Program komputer, struktur data dan dokumentasi yang saling berhubungan dan memberikan efek pada metode, prosedur dan kontrol yang diinginkan. 2. Hardware Peralatan elektronik, (misalnya CPU, memory) yang memberikan kemampuan komputasi serta peralatan elektromedia (misalnya sensor, motor, pompa) yang memberikan fungsi external. 3. People / Brainware User dan operator dari hardware dan software 4. Database
Sekumpulan informasi yang besar, yang diorganisir agar dapat diakses oleh software dan merupakan bagian integral dari fungsi sistem. 5. Prosedur Langkah-langkah yang menetapkan pemakaian khusus untuk setiap elemen sistem.
PROCEDURE
DATABASE
INPUT
HARDWARE
OUTPUT
SYSTEM
DOCUMENT
SOFTWARE
PEOPLE
Gambar 6.1.: elemen system berbasis komputer Pemodelan system Menentukan proses yang melayani kebutuhan sesuai dengan konsideran yang ada. Menampilkan perilaku proses dan asumsi dimana perilaku itu berada. Secara eksplisit menentukan input exogen dan endogen pada model. Input exogen menghubungkan satu konstituen dan satu pandangan dengan konstituen lain pada tingkat yang sama di level yang lain. Input endogen menghubungkan komponen individu pada konstituen pada pandangan khusus. Menampilkan seluruh kaitan (termasuk output) yang memungkinkan engineer mempunya pemahaman yang lebih baik Pemodelan system secara hierarkhi
Gambar 6.2. : Pemodelan system hyrarkhi
Arsitektur Sistem Didalam pengembangan system gambaran mengenai arsitektur system diharuskan, adapun arsitektur yang dibutuhkan untuk mendukung proses analisis dan desain system sesuai tujuan bisnis Tiga arsitektur yang berbeda harus dianalisis dan didesain dalam konteks tujuan bisnis: Arsitektur data Arsitektur aplikasi Arsitektur teknologi Arsitektur data menyediakan bingkai kerja untuk kebutuhan infromasi dari bisnis atau fungsi bisnis Arsitektur aplikasi mencakup elemen-elemen sistem yang mentransformasi objek dalam arsitektur data untuk tujuan bisnis Infrastruktur teknologi menyediakan pondasi untuk arsitektur data dan arsitektur aplikasi Hierarkhi BPE Information strategy planning (ISP)
o o o
Tujuan strategis ditentukan Faktor sukses/aturan bisnis ditentukan Model perusahaan dibuat
Business area analysis (BAA) o o
Proses/layanan dimodelkan Inter-relasi proses dan data
Application Engineering o o
RPL Pemodelan aplikasi/prosedur yang merujuk pada BAA dan batasanbatasan ISP
Construction and delivery o
menggunakan CASE dan 4GTs, pengujian
Didalam melakukan informationa strategy planning (ISP) diperlukan informasi isuisu seperti : Isu manajemen o o o o
Menentukan tujuan bisnis strategis Isolasi critical success factors Melakukan analisis pada pengaruh teknologi Melakukan analisis pada sistem strategis
Isu teknis o o o
Membuat model data tingkat tertinggi Dikelompokkan berdasar area bisnis/organisasi Memperbaiki model dan clustering
Menentukan tujuan dan sasaran : Tujuan—pernyataan umum tentang arahan Sasaran—menentukan tujuan yang bisa diukur : mengurangi biaya pabrik pada produk o Sub Sasaran: Menurunkan angka reject dengan 20% di dalam 6 bulan pertama Memperoleh konsesi 10% dari supplier re-engineer 30% dari komponen untuk fabrikasi yang lebih mudah selama tahun pertama Tujuan cenderung strategis, sasaran cenderung taktis
Business Area Analysis Menemukan “pengelompokan fungsi dan data bisnis yang secara natural kohesif” (Martin) Melakukan aktivitas yang banyak sama dengan ISP, tetapi lingkupnya lebih dekat ke area bisnis individual Mengenali sistem informasi yang telah ada sebelumnya/menentukan kompatibilitas dengan model ISP baru o Menentukan sistem yang bermasalah o Menemukan sistem yang tidak kompatibel dengan model informasi baru o Mulai membuat prioritas re-engineering
Gambar 6.3. : Proses BAA
Rekayasa Produk
Gambar 6.4. : Rekayasa Produk Template Arsitektur produk
Gambar 6.5. : Template Arsitektur Produk
Gambar 6.6. : Diagram Arsitektur Flow Diagram Pemodelan system dengan UML o
Deployment diagrams ê Setiap box 3D menggambarkan elemen perangkat keras yang merupakan bagian arsitektur fisik dari sistem o Activity diagrams ê Menampilkan aspek prosedural dari elemen sistem o Class diagrams ê Menampilkan elemen tingkat sistem dalah hal data yang menjelaskan elemen dan operasi yang memanipulasi data tersebut
These and other UML models will be discussed later Deployment Diagram Deployment diagram digunakan untuk memvisualisasikan topologi komponen fisik dari sebuah sistem dimana komponen perangkat lunak yang digunakan. Jadi deployment diagram digunakan untuk menjelaskan pandangan penyebaran statis dari sebuah sistem. Deployment diagram terdiri dari node dan hubungan mereka. http://www.tutorialspoint.com/uml/uml_deployment_diagram.htm
CLSS processor
Operat or display
Sort ing subsyst em
Sensor dat a acquisit ion subsyst em
Conveyor Pulse t ach
shunt cont roller
Shunt act uat or
Bar code reader
Gambar 6.7. : Deployment Diagram Activity Diagram Activity diagram adalah diagram lain yang penting dalam UML untuk menggambarkan aspek dinamis dari sistem. Diagram aktivitas pada dasarnya adalah diagram alir untuk mewakili aliran bentuk satu kegiatan dengan kegiatan lain. Kegiatan dapat digambarkan sebagai operasi dari sistem. Jadi aliran kontrol diambil dari satu operasi yang lain. Aliran ini bisa berurutan, bercabang atau bersamaan. Activity diagram berhubungan dengan semua jenis kontrol aliran dengan menggunakan unsur-unsur yang berbeda seperti garpu, dll bergabung
st a rt c o n v e y o r l i n e
g e t c o n v e y o r sp e e d
re a d b a r c o d e
v alid bar c ode
inv alid bar c ode
det er m ine bin loc at ion
se t f o r re j e c t b i n
se n d sh u n t c o n t ro l d a t a
g e t sh u n t st a t u s
g e t c o n v e y o r st a t u s
re a d b a r c o d e
p ro d u c e re p o rt e n t ry
c onv ey or s t opped
c onv ey or in m ot ion
Gambar 6.8. : Diagram Activity Class Diagram Class Diagram adalah diagram statis. sebuah aplikasi. Diagram kelas tidak hanya menggambarkan dan mendokumentasikan aspek untuk membangun kode dieksekusi dari aplikasi
Ini merupakan pandangan statis dari digunakan untuk memvisualisasikan, yang berbeda dari sistem tetapi juga perangkat lunak.
Diagram kelas menggambarkan atribut dan operasi kelas dan juga kendala yang dikenakan pada sistem. Diagram kelas yang banyak digunakan dalam pemodelan sistem berorientasi objek karena mereka adalah satu-satunya diagram UML yang dapat dipetakan secara langsung dengan bahasa berorientasi objek. Diagram kelas menunjukkan koleksi kelas, interface, asosiasi, kolaborasi dan kendala. Hal ini juga dikenal sebagai diagram struktural. class name
Box barcode forwardSpeed conveyorLocat ion height widt h dept h weight cont ent s readBarcode( ) updat eSpeed ( ) readSpeed( ) updat eLocat ion( ) readLocat ion( ) get Dimensions( ) get Weight( ) checkCont ent s( )
at t ribut es not e use of capit al let t er f or mult i-word at t ribut e names
operat ions ( parent heses at end of name indicat e t he list of at t ribut es t hat t he operat ion requires)
Gambar 6.9. : Class Diagram
Bab 7 Rekayasa Kebutuhan
Tujuan Pembelajaran Umum Mendeskripsikan Perangkat Lunak Praktis Tujuan Pembelajaran Khusus Mampu Mengidentifikasikan Rekayasa Kebutuhan Rekayasa Kebutuhan Permulaan (Inception)-Menetapkan pemahaman dasar dari masalah dan sifat dari solusi.
Pemahaman dasar dari masalah Orang yang membutuhkan solusi Keadaan dari solusi yang diinginkan Efektivitas komunikasi dan kolaborasi awal antara konsumen dengan developer
Perolehan (Elicitation) – Memperoleh kebutuhan dari para pemangku kepentingan (Stakeholder). Penguraian (Elaboration) -Buat model analisis yang mewakili informasi, fungsional, dan aspek perilaku dari persyaratan. Negosiasi (Negociation)-Setuju pada sistem penyampaian yang realistis untuk pengembang dan pelanggan. Spesifikasi (Specification) -Jelaskan persyaratan formal maupun informal.
Dokumen tertulis Sekelompok model Matematika formal Sekumpulan skenario user (use-cases) Prototipe
Validisai (Validation) -Review spesifikasi persyaratan untuk kesalahan, ambiguitas, kelalaian, dan konflik. Kesalahan isi atau interpretasi Area dimana klarifikasi dibutuhkan Informasi yang hilang
inkonsistensi (masalah utama ketika produk atau sistem besar direkayasa) Kebutuhan yang konflik atau tidak realistis. Kebutuhan Manajemen (Requirement Management) - Mengelola perubahan kebutuhan. Permulaan Siapa di balik permintaan untuk pekerjaan ini? Siapa yang akan menggunakan solusi (produk / sistem)? Apa yang akan menjadi manfaat ekonomi? Bagaimana Anda mencirikan "baik" output dari sistem? Masalah apa ini alamat solusi? Lingkungan apa yang akan produk digunakan dalam? Apakah Anda orang yang tepat untuk menjawab pertanyaan-pertanyaan ini? Apakah pertanyaan ini relevan? Dapatkah orang lain memberikan informasi tambahan? Haruskah saya meminta Anda yang lain? Mendapatkan persyaratan yang baik "Yang paling sulit tunggal bagian dari membangun sistem perangkat lunak adalah memutuskan apa untuk membangun. Tidak ada bagian dari pekerjaan sehingga melumpuhkan sistem yang dihasilkan jika dilakukan salah. Tidak ada bagian lain yang lebih sulit untuk memperbaiki nanti. " -Fred Brooks "Benih-benih bencana software yang besar biasanya ditaburkan dalam tiga bulan pertama dimulainya proyek perangkat lunak." -Capers Jones "Kami menghabiskan banyak waktu mayoritas usaha proyek tidak menerapkan atau pengujian, tetapi mencoba untuk memutuskan apa yang harus membangun." -Brian Lawrence
Memunculkan persyaratan Mengapa begitu sulit untuk secara jelas memahami apa yang diinginkan oleh pelanggan?
cakupan • •
Batas sistem ini tidak jelas. Pelanggan / pengguna menentukan detail teknis yang tidak perlu yang dapat membingungkan daripada memperjelas tujuan.
Memahami • • • • • • •
Pelanggan tidak sepenuhnya yakin apa yang dibutuhkan. Pelanggan memiliki pemahaman yang buruk tentang kemampuan dan keterbatasan lingkungan komputasi. Pelanggan tidak memiliki pemahaman penuh domain masalah mereka. Pelanggan memiliki kesulitan berkomunikasi kebutuhan kepada insinyur sistem. Pelanggan menghilangkan detail yang diyakini jelas. Pelanggan menentukan persyaratan yang bertentangan dengan persyaratan lainnya. Pelanggan menentukan persyaratan yang tidak jelas atau teruji.
Kegembiraan terjadi jika : •
Persyaratan berubah seiring waktu.
Mengumpulkan persyaratan kolaborasi • • • • • •
Rapat yang dihadiri oleh seluruh pemangku kepentingan (stakeholder). Aturan yang ditetapkan untuk persiapan dan partisipasi. Agenda harus cukup formal untuk menutup semua poin-poin penting, tapi cukup informal untuk mendorong aliran bebas ide. Seorang fasilitator mengendalikan pertemuan. Definisi Mekanisme (papan tulis, flip chart, dll) yang digunakan. Dalam pertemuan tersebut: o Masalah diidentifikasi. o Elemen dari solusi yang diusulkan. o Pendekatan yang berbeda dinegosiasikan. o Satu set awal persyaratan solusi diperoleh. o Atmosfer kolaboratif dan non-mengancam
Quality Function Development •
Penyebaran fungsi (function deployment) menentukan "nilai" (kepada pelanggan) dari setiap fungsi yang diperlukan dari sistem.
• • •
Penyebaran informasi (information deployment) mengidentifikasi objek data dan peristiwa. Penyebaran tugas (task deployment) meneliti perilaku sistem. Analisis Nilai (value analysis) menentukan prioritas kebutuhan.
Elisitasi kerja produk • • • • • • •
Pernyataan kebutuhan dan kelayakan. Pernyataan lingkup. Daftar peserta dalam elisitasi persyaratan. Deskripsi lingkungan teknis sistem. Daftar persyaratan dan kendala domain terkait. Daftar skenario penggunaan. Setiap prototipe dikembangkan untuk memperbaiki persyaratan.
USE CASE •
• • •
Skenario use case adalah cerita tentang bagaimana seseorang atau sesuatu eksternal untuk perangkat lunak (dikenal sebagai aktor) berinteraksi dengan sistem. Setiap skenario menjawab pertanyaan-pertanyaan berikut: Siapakah aktor utama, aktor sekunder (s)? Apa tujuan aktor? o Prasyarat apa yang harus ada sebelum cerita dimulai? o Apa tugas atau fungsi utama yang dilakukan oleh aktor? o Pengecualian apa yang mungkin dianggap sebagai cerita digambarkan? o Apa variasi dalam interaksi aktor yang mungkin? o Apa sistem informasi akan aktor memperoleh, memproduksi, atau mengubah? o Apakah aktor harus menginformasikan sistem tentang perubahan dalam lingkungan eksternal? o Informasi apa yang diharapkan aktor dari sistem? o Apakah aktor ingin diberitahu tentang perubahan yang tak terduga
Elemen Model Analisis Elemen-berbasis skenario • •
Gunakan-kasus Bagaimana aktor eksternal berinteraksi dengan sistem (diagram use case, template rinci) Fungsional-Bagaimana fungsi perangkat lunak yang diproses dalam sistem (flow chart, diagram aktivitas)
Elemen berbasis kelas •
Berbagai objek sistem (diperoleh dari skenario) termasuk atribut dan fungsi (diagram kelas) mereka
• •
elemen perilaku Bagaimana sistem berperilaku dalam menanggapi peristiwa yang berbeda (diagram negara)
Elemen-berorientasi Arus •
Bagaimana informasi berubah seakan mengalir melalui sistem (diagram alir data)
Use Case Diagram
Gambar 7.1. : Diagram Use Case
Gambar 7.2. : Diagram Activity untuk RE
Gambar 7.3. : Diagram Class
Gambar 7.4.: Diagram State Analisis Pola • • • •
Nama Pola: Menangkap esensi dari pola. Intent: Apa pola menyelesaikan atau mewakili. Motivasi: Sebuah skenario yang menggambarkan bagaimana pola memecahkan masalah. Pasukan dan konteks: isu-isu eksternal (kekuatan) yang mempengaruhi bagaimana pola yang digunakan, dan isu-isu eksternal diselesaikan ketika pola diterapkan.
• • • • •
Solusi: Bagaimana pola ini diterapkan untuk memecahkan masalah, menekankan masalah struktural dan perilaku. Konsekuensi: Apa yang terjadi ketika pola ini diterapkan, apa trade-off yang ada selama aplikasi tersebut. Desain: Bagaimana pola dapat dicapai melalui pola desain dikenal. Dikenal penggunaan: Contoh penggunaan dalam sistem yang sebenarnya. Pola Terkait: Pola berkaitan dengan pola bernama karena 1. mereka biasanya digunakan dengan pola bernama; 2. mereka secara struktural mirip dengan pola bernama; 3. mereka adalah variasi dari pola bernama.
Kebutuhan Negosiasi • • •
Mengidentifikasi stakeholder kunci o Inilah orang-orang yang akan terlibat dalam negosiasi Tentukan setiap stakeholder "kondisi menang" o Kondisi Win tidak selalu jelas Merundingkan o Bekerja ke arah satu set persyaratan yang mengarah ke "menangmenang"
Kebutuhan Validasi 1. Apakah 2. Apakah 3. Apakah 4. Apakah 5. Apakah 6. Apakah 7. Apakah 8. Apakah 9. Apakah 10. Apakah 11. Apakah
setiap persyaratan yang konsisten dengan tujuan sistem? semua persyaratan telah ditetapkan pada tingkat abstraksi yang tepat? persyaratan yang benar-benar diperlukan? kebutuhan masing-masing dibatasi dan tidak ambigu? kebutuhan masing-masing memiliki atribusi? ada konflik dengan persyaratan persyaratan lainnya? kebutuhan masing-masing dicapai dalam lingkungan teknis sistem? setiap kebutuhan dapat diuji, sekali diterapkan? model mencerminkan sistem informasi, fungsi dan perilaku? model telah tepat "dipartisi"? pola persyaratan yang sesuai telah digunakan?
Contoh rapat CRG Pertemuan CRG proyek pertama SafeHome. •
•
Setelah sesi tanya jawab (pertemuan awal), pemangku kepentingan menulis permintaan produk dua halaman, yang disampaikan kepada mereka yang menghadiri pertemuan pertama CRG. Peserta diminta untuk membuat daftar kasar benda, jasa, kendala, dan kriteria kinerja untuk produk.
• • • •
•
•
• • •
Pada pertemuan tersebut, daftar gabungan dibuat dalam setiap topik. Subkelompok menulis mini-spesifikasi untuk setiap item daftar. Fitur yang relevan di mini-spesifikasi yang ditambahkan ke dalam daftar. Penelitian kami menunjukkan bahwa pasar untuk sistem manajemen rumah tumbuh pada tingkat 40 persen per tahun. Fungsi SafeHome pertama kita bawa ke pasar harus menjadi fungsi keamanan rumah. Kebanyakan orang yang akrab dengan "sistem alarm" jadi ini akan menjadi mudah dijual. Fungsi keamanan rumah akan melindungi dan / atau mengenali berbagai diinginkan "situasi" seperti masuknya ilegal, kebakaran, banjir, tingkat karbon monoksida, dan lain-lain. Ini akan menggunakan sensor nirkabel untuk mendeteksi setiap situasi, dapat diprogram oleh pemilik rumah, dan secara otomatis akan menelepon agen pemantauan ketika situasi terdeteksi. Objek - panel kontrol, detektor asap, jendela dan sensor pintu, detektor gerakan, alarm, sebuah acara (sensor telah diaktifkan), display, PC, nomor telepon, panggilan telepon, ... Jasa - mengkonfigurasi sistem, pengaturan alarm, pemantauan sensor, panggilan telepon, pemrograman panel kontrol, membaca layar, ... Kendala - Sistem harus mengenali kapan sensor tidak beroperasi, harus user friendly, harus berhubungan langsung ke saluran telepon standar, ... Kriteria kinerja - acara Sensor harus diakui dalam satu detik, skema prioritas acara harus dilaksanakan, ...
Bab 8 Pemodelan Analisis
Tujuan Pembelajaran Umum Mendeskripsikan Perangkat Lunak Praktis Tujuan Pembelajaran Khusus Mampu Mengidentifikasikan pemodelan analisis
Analisis Kebutuhan Analisis Kebutuhan o Menentukan karakteristik operasional PL o Menunjukkan antarmuka PL dengan elemen sistem yang lain o Membuat batasan yang harus dipenuhi PL Analisis Kebutuhan memungkinkan Software Engineer (disebut analis atau modeler) untuk: o Memperinci kebutuhan dasar yang dibuat kapda rekayasa kebutuhan sebelumnya o Membangun model yang dapat menggambarkan skenario user, aktivitas fungsional, class masalah dan relasinya, sistem dan perilaku class, dan aliran data ketika ditransformasikan.
Sebuah Jembatan
system description
analysis model
design model
Gambar 8.1.: Jembatan yang menghubungkan deskripsi system, model analisis dan model desain
Analisis Domain Analisis domain PL adalah identifikasi, analisis, dan spesifikasi kebutuhan umum dari domain aplikasi tertentu, yang biasanya digunakan kembali pada project lain di dalam domain aplikasi yang sama [Analisis domain berorientasi objek adalah] identifikasi, analisis dan spesifikasi kemampuan umum, kemampuan digunakan kembali dalam domain tertentu dalam istilah- istilah objek, class, subassemblies dan framework umum Donald Firesmith
Cara melakukan analisis domain o Tentukan domain yang ingin diinvestigasi. o Kumpulkan contoh representatif aplikasi pada domain tersebut. o Analisis setiap aplikasi pada contoh. o Kembangkan model analisis untuk objek. Pemodelan data o o o o
Memeriksa objek data secara independen terhadap proses Fokus perhatikan pada domain data Membuat sebuah model pada abstraksi level konsumen Mengindikasikan bagaimana objek data berhubungan satu dengan yang lain
Apa itu objek data o Objek adalah sesuatu yang menjelaskan atribut (item-iten data) dan dapat dimanipulasi di dalam perangkat lunak (system). o Masing-masing Instant Object : Book , dapat diidentifikasikan secara unik : ISBN o Masing-masing memainkan peran dalam system, system tidak akan berfungsi tanpa adanya objek instant o Masing-masing dijelaskan dengan atribut mengenai item data dirinya Objek-objek umum -
Entitas eksternal (printer, user, sensor) Sesuatu (laporan, display, sinyal) Kejadian atau level (interupsi, alarm) Orang (manager, engginer, salesperson) Unit organisai (divisim tim) Tempat (lantai pabrik) Struktur (employee record)
Apa yang dimaksud dengan relationship ? Relationship – menandakan kaitan, sebuah fakta yang harus diingat oleh sistem, tidak dikomputasi atau diturunkan secara mekanis Beberapa instant adalah sebuah hubungan dapat dijalankan Objek dapat direlasikan melalui cara yang berbeda-beda
Gambaran Notasi ERD
Gambar 8.2.: Notasi ERD Bagaimana cara membangun ERD o Level 1—modelkan semua objek data (entitas) dan koneksinya dengan yang lain o Level 2—modelkan semua entitas dan relasi o Level 3—modelkan semua entitas, relasi, dan atribut yang menyediakan informasi yang lebih mendalam Contoh ERD
Gambar 8.3.: ERD Rumah Sakit sumber : http://www.smartdraw.com/resources/glossary/entity-relationshipdiagram/
Konsep Orientasi Objek : Harus dipahami untuk menerapkan elemen berbasis class pada model analisis Konsep-konsep kunci: o Classes dan objects o Attributes dan operations o Encapsulation dan instantiation o Inheritance Class • Pemikiran object-oriented dimulai dengan sebuah class, sering didefinisi sebagai : – template – deskripsi umum – “blueprint” ... Menggambarkan sekelompok item yang mirip • sebuah metaclass (sering disebut superclass)yang membangun hierarki semua class yang ada • Sekali sebuah class item ditentukan, instance spesifik dari class tersebut dapat diidentifikasi
Berikut ini adalah contoh bangunan sebuah class :
Gambar 8.4.: Class Apakah Class occurrences
roles organizational units
things
places external entities structures
class name a
op
Gambar : 8.5. Proses Class
Enkapsulisasi (Penyembunyian) Objek mengenkapsulasi baik data dan prosedur logis yang dibutuhkan untuk manipulasi data
method #2
method #1 data
method #3
method #6
method #5
method #4
Gambar 8.6.: Penyembunyian informasi Hierarkhi Class PieceOfFurniture (superclass)
Table
Chair
Desk
”Chable"
subclasses of the
instances of Chair
Gambar 8.7.: Hirarkhi Class Metode (operasi/layanan) Prosedur yang terenkapsulasi pada sebuah class dan didesain untuk beroperasi pada satu atau lebih atribut data yang ditentukan sebagai bagian dari class. Method dipanggil melalui pesan Model berbasis Scenario “[Use-cases] adalah bantuan untuk mendefinisikan apa yang ada pada sistem (aktor) dan apa yang harus dilakukan sistem (use-cases).” Ivar Jacobson (1) Apa yang harus ditulis? (2) Berapa banyak kita harus menulisnya? (3) Sedetail apa gambaran kita ? (4) Bagaimana kita mengatur deskripsi? Skenario Sebuah skenario yang menggambarkan rangkaian kegunaan pada sistem
actors mewakili peran orang atau piranti yang dimaikan ketika sistem berfungsi users dapat berperan sebagai lebih dari satu peran dalam sebuah skenario yang ditentukan Mengembangkan use case Apa tugas atau fungsi utama yang harus dilakukan aktor ? Sistem Informasi seperti apa yang diperlukan, dihasilkan atau diubah oleh aktor ? Apakah aktor harus menginformasikan sistem tentang perubahan dalam lingkungan eksternal? Informasi apa yang diharapkan aktor dari sistem? Apakah aktor menginginkan diberitahu tentang perubahan yang tidak tersangka? Use Case Diagram Saf eHome
Access camera surveillance via t he Int ernet
Conf igure Saf eHome syst em paramet ers homeowner
Set alarm
Gambar 8.8. : Diagram Use Case
cameras
Diagram aktifitas : Melengkapi use-case dengan menyediakan representasi diagram dari aliran prosedural.
ent er password and user ID
invalid passwor ds/ ID
valid passwor ds/ ID
selec t major f unct ion
prompt f or reent ry
ot her f unct ions m ay also be select ed input t r ies r em ain
select surv eillance no input t r ies r em ain
t hum bnail views
select a specif ic cam er a
select specif ic camera - t humbnails
select camera ic on
view camera out put in labelled window
prompt f or anot her v iew
exit t his f unct ion
see anot her cam er a
Gambar 8.9. : Diagram Aktifitas
Diagram Swimlane : Memungkinkan untuk menampilkan aliran aktivitas yang digambarkan oleh use-case, dan di saat yang sama mengindikasikan aktor yang mana, atau class analisis yang mempunyai tanggungjawab terhadap tindakan yang digambarkan oleh kotak aktivitas
homeowner
c a m e ra
i n t e rf a c e
ent er password and user ID
valid p asswo r d s/ ID in valid p asswo r d s/ ID
select m ajor f unct ion o t h er f u n ct io n s m ay also b e select ed
prom pt f or reent ry
in p u t t r ies r em ain
select surveillance n o in p u t t r ies r em ain
t h u m b n ail views
select a sp ecif ic cam er a
select specif ic cam era - t hum bnails
select cam era icon
generat e video out put prom pt f or anot her view
view cam era out put in labelled window
exit t h is f u n ct io n see an o t h er cam er a
Gambar 8.10 : Diagram Swimlane Pemodelan berorientasi aliran Menampilkan bagaimana objek data ditransformasi ketika mereka bergerak di dalam sistem Sebuah data flow diagram (DFD) merupakan bentuk diagram yang digunakan Walaupun dianggap pendekatan kuno, pemodelan berorientasi aliran menyediakan pandangan unik terhadap suatu sistem. Dia tetap layak digunakan untuk mendukung analisis elemen model lainnya. Model Aliran Setiap sistem berbasis komputer Adalah sebuah transformasi informasi Input – system berbasis computer – output
Notasi Model Aliran
Gambar 8.11. Notasi dalam diagram ER Menyimpan data
Data disimpan untuk digunakan lagi. sensor #
report required
look-up sensor data sensor number
sensor #, type, location, age
type, location, age sensor data
Gambar 8.12. : ERD Menyimpan data Petunjuk menggambar ERD o Semua icon harus diberi nama yang bermakna jelas o DFD berkembang dalam beberapa tingkatan o Selalu dimulai dengan sebuah context level diagram (level 0) o Selalu menunjukkan entitas eksternal pada level 0 o Selalu berinama panah aliran data
o Jangan menampilkan prosedur logika
Membangun DFD level -1 o Mereview model data untuk mengisolasi objek data dan gunakan parsing gramatikal untuk menentukan “Operasi” o Menentukan entitas eksternal (produsen dan konsumen data) o Membuat level 0 DFD Contoh : Level 0 DFD user
processing request
digital video processor video source
requested video signal
monitor
NTSC video signal
Gambar 8.13. : DFD level 0 Membangun DFD level-2 o Tulis sebuah narasi yang menggambarkan transformasi o Parsing untuk menentukan transformasi tingkat berikutnya o “seimbangkan” aliran untuk menjaga aliran data o Bangun level 1 DFD o Gunakan rasio 1:5 (perkiraan) Contoh : Level 1 DFD Hierarkhi Aliran Data
x
a
a
b
P
c
p2
level 1
p4 p3
level 0
f
p1
d
y
e
g
5
b
Gambar 8.14. : Hierarkhi Aliran Data Catatan penting DFD o Setiap lingkaran harus dipecah hingga dia hanya melakukan hanya SATU hal o Rasio ekspansi menurun sesuai dengan jumlah level yang meningkat
o Kebanyakan sistem membutuhkan antara 3 hingga level 7 untuk model aliran yang cukup. o Sebuah item aliran data (panah) dapat dikembangkan seiring dengan meningkatnya level (data dictionary menyediakan informasi ini) Spesifikasi Proses Lingkaran
PSPEC naratif pseudocode (PDL) persamaan tabel Diagram dan atau grafik
Gambar 8.15. : Spesifikasi Proses Setelah melakukan DFD, selanjutnya adalah :
analysis model
Maps into
design model
Gambar 8.16 : Model Analisis dilanjutkan ke Model Desain Control Flow Diagram Menggambarkan “events” dan proses yang mengelola event Sebuah “event” adalah kondisi boolean yang dipastikan dengan : Mendaftar semua sensor yang dibaca oleh software. Mendaftar semua kondisi interupsi. Mendaftar semua "switches" yang dipicu oleh sebuah operator. Mendaftar semua kondisi data. Memanggil kembali parser kata benda/kerja yang diaplikasikan pada narasi proses, mereview semua “item kendali” sebagai input/output CSPEC. Model Kendali
• • •
• • • •
control flow diagram berada “di atas” DFD dan menunjukkan event yang mengendalikan proses-proses yang terdapat pada DFD Aliran kendali—event dan item kendali– ditandai dengan panah putus-putus Sebuah tiang vertikal menggambarkan input menuju atau output dari sebuah control spec (CSPEC) — spesifikasi terpisah yang menggambarkan bagaimana kendali ditangani Sebuah panah putus-putus memasuki tiang vertikal adalah input menuju CSPEC Sebuah panah putus-putus meninggalkan proses menggambarkan kondisi data Sebuah panah putus-patas memasuki sebuah proses menggambarkan sebuah kendali input yang dibaca langsung oleh proses Aliran kendali tidak secara fisik mengaktifkan/menonaktifkan proses, hal ini dilakukan melalui CSPEC
Contoh Control Flow Diagram copies done beeper on/off read operator input
start
empty
problem light
manage copying
reload process
full
create user displays
perform problem diagnosis
display panel enabled jammed
Gambar 8.17 : Control Flow Diagram CSPEC terdiri dari : state diagram ( sequential specification), state transition table, decisions tables and activation tables, atau bisa juga merupakan spesifikasi kombinasi (combinational specification) Panduan membangun CSPEC - Lihat semua sensor yang dibaca PL - Lihat semua control interupsi - Lihat semua switches yang diaktifkan oleh operator - Lihat semua kondisi data - Melihat parsing kata benda/kerja yang diterapkan pada statement software atau lingkupnya mereview semua item kendali sebagai input/output CSPES yang mungkin - Menggambarkan perilaku sebuah system dengan identifikasi keadaan menentukan bagaimana setiap kedadaan mencapai dan menentukan transisi antar keadaan.
-
Fokus pada kemungkinan kehilangan/tidak tercantum.. Kesalahan umum dalam menentukan kendali, misalnya : “is there any other way I can get this state or exit from it?”
Pemodelan berbasis class • • • •
Tentukan analisis class dengan memeriksa pernyataan masalah(problem statement) Gunakan parsing gramatikal untuk memilah class potensial Kenali atribut tiap class Kenali operasi yang memanipulasi atribut-atribut tersebut
Analisis Class : • • • • • • •
Entitias external (contoh : sistem lain, piranti, orang) yang menghasilkan atau menggunakan informasi yang digunakan oleh sistem berbasis komputer. Benda (contoh : laporan, display, surat, sinyal) yang merupakan bagian dari domain informasi untuk masalah. Kejadian atau event (contoh : transfer properti atau pelengkapan urutan gerakan robot) yang terjadi di dalam konteks sistem operasi. Peran (contoh : manajer, insinyur, sales) yang diperankan orang yang berinteraksi dengan sistem. Unit Organisasi (contoh : divisi, kelompok, tim) yang relevan terhadap aplikasi. Tempat (contoh : lantai pabrik, pelabuhan muatan) yang membangun konteks masalah dan fungsi keseluruhan sistem. Struktur (contoh : sensor, kendaraan 4WD, komputer) yang terdiri dari beberapa objek class atau objek-objek class yang terkait
Kriteria memilih class : • • • • • •
Menyimpan informasi Layanan yang dibutuhkan Beberapa output Atribut umum Operasi umum Kebutuhan esensial
Gambar Class Diagram
Class name System systemID verificationPhoneNumber systemStatus delayTime telephoneNumber masterPassword temporaryPassword numberTries
attributes
program() display() reset() query() modify() call()
operations
Gambar 8.18 : Diagram Class
Contoh Class Diagram FloorPlan type name outsideDimensions
determineType ( ) positionFloorplan scale( ) change color( )
is placed wit hin is part of
Wall
Cam era t y pe ID loc at ion f ieldV iew panA ngle Zoom Set t ing
t y pe wallDim ens ions
determineType ( ) computeDimensions ( )
det erm ineTy pe () t rans lat eLoc at ion () dis play ID() dis play V iew() dis play Zoom ()
is used t o build
is used t o build is used t o build
WallSegm ent t y pe s t art Coordinat es s t opCoordinat es nex t WallSem ent
determineType ( ) draw( )
Door
Window t y pe s t art Coordinat es s t opCoordinat es nex t Window
t y pe s t art Coordinat es s t opCoordinat es nex t Door
determineType ( ) draw( )
determineType ( ) draw( )
Gambar 8.19.: Class Diagram Pemodelan CRC Class-class analisis memiliki “tanggung-jawab”
o Tanggungjawab adalah atribut-atribut dan operasi-operasi yang terenkapsulasi oleh class Class-class analisis berkolaborasi satu dengan yang lain o Collaborators adalah class-class yang dibutuhkan untuk menyediakan sebuah class dengan informasi yang dibutuhkan untuk memenuhi tanggung jawabnya. o Secara umum, sebuah kolaborasi berakibat permintaan informasi atau permintaan beberapa aksi/operasi. Contoh Pemodelan CRC Class: Class: Description: Class: Description: Class: FloorPlan Description: Responsibility: Description: Responsibility: Responsibility: Responsibility:
Collaborator: Collaborator: Collaborator: Collaborator:
defines floor plan name/type manages floor plan positioning scales floor plan for display scales floor plan for display incorporates walls, doors and windows
Wall
shows position of video cameras
Camera
Tipe-tipe class Class entitas, sering disebut class model atau bisnis, yang diekstrak langsung dari statemen permasalahan (contoh : Sensor). Class perbatasan digunakan untuk membuat interface (contoh : layar interaktif, atau laporan cetak) dimana user melihat dan berinteraksi dengannya selama PL digunakan. Class kendali mengelola “unit kerja [UML03] dari awal sampai akhir. Class kendali dapat didesain mengelola : o Pembuatan atau update objek entitas; o Inisiasi objek perbatasan sebagaimana mereka mendapatkan informasi dari objek entitas; o Komunikasi kompleks antara sekumpulan objek; o Validasi data yang dikomunikasikan antara user dan aplikasi. Responsibility
• • • • •
Kecerdasan system harus didistribusikan di kelas terbaik untuk mengatasi masalah kebutuhan Setiap tanggung jawab harus memungkinkan dinyatakan secara umum Informasi dan perilaku yang berkaitan dengan itu harus berada dalam kelas yang sama Informasi tentang yang satu hal harus dilokalisasi dengan satu kelas, tidak didistribusikan di beberapa kelas. Tanggung jawab (responsibility) harus dibagi di antara kelas terkait, bila perlu.
Kolaborasi Class memenuhi tanggung jawabnya dengan satu diantara dua cara : o Sebuah class dapat menggunakan operasinya sendiri untuk memanipulasi atributnya masing- masing atau o Sebuah class dapat berkolaborasi dengan class lainnya. Kolaborasi membuat relasi antara class Kolaborasi dapat diidentifikasi dengan menentukan apakah sebuah class dapat memenuhi tanggung jawabnya masing- masing Tiga relasi umum yang berbeda antar class [WIR90]: o is-part-of relationship o has-knowledge-of relationship o depends-upon relationship Composite Agragate Class
Player
PlayerHead
PlayerBody
PlayerArms
PlayerLegs
Gambar 8.20 : Composite Agregate Class
Review Model CRD Semua peserta dalam review (model CRC) diberikan sebuah subset dari kartu index model CRC. o Kartu yang berkolaborasi harus terpisah (tidak boleh ada reviewer yang memiliki dua kartu yang berkolaborasi). Semua skenario use-case (dan diagram use case terkait) harus diorganisasi dalam kategori-kategori. Pemimpin review membaca use-case secara hati-hati. o Ketika pemimpin review sampai pada objek, dia akan memberi tanda kepada person yang memegang kartu index class yang terkait. Ketika tanda dikirimkan, pemilik kartu class diminta untuk menggambarkan tanggung jawab yang tertulis di kartu tersebut. o Kelompok menentukan satu (atau lebih) tanggung jawab yang memenuhi kebutuhan use-case. Jika tanggung jawab dan kolaborasi yang tertera pada kartu index tidak dapat mengakomodasi use-case, modifikasi dilakukan pada kartu tersebut. o Hal ini termasuk definisi class baru (dan kartu index CRC) atau spesifikasi baru atau revisi mengenai tanggung jawab, atau kolaborasi kartu yang sudah ada. Asosiasi dan Dependensi Dua class analisis sering berhubungan satu dengan yang lain dalam beberapa pola o Dalam UML relasi ini sering disebut asosiasi o Asosiasi dapat didapatkan dengan mengenali multiplicity (istilah cardinality digunaikan dalam pemodelan data Dalam banyak instans, relasi client-server ada diantara dua class analisis. o Dalam kasus ini, class client tergantung pada class server dalam suatu cara dan relasi dependensi terjadi Multiplicity Hubungan asosiasi menunjukkan bahwa (setidaknya) salah satu dari dua kelas terkait membuat referensi ke yang lain. Berbeda dengan hubungan generalisasi, ini paling mudah dipahami melalui frase 'A memiliki B' (kucing ibu memiliki anak kucing, anak kucing memiliki induk kucing). UML representasi asosiasi adalah garis dengan panah opsional yang menunjukkan peran dari objek (s) dalam hubungan, dan notasi opsional pada setiap akhir menunjukkan banyaknya contoh entitas (jumlahobjek yang berpartisipasi dalam asosiasi).
Wall
1 is used to build
1
1 is used to build
0..* is used to build
1..* WallSegm ent
Window
Door
Gambar 8.21: Multiplicity
0..*
Dependency Hubungan yang menunjukkan bahwa elemen, atau set elemen, membutuhkan elemen model lainnya untuk spesifikasi atau pelaksanaannya [1] Unsur tergantung pada unsur independen, disebut pemasok.. Dua atau lebih elemen dalam hubungan ini disebut tupel. Dalam UML, hal ini ditunjukkan dengan garis putus-putus menunjuk dari dependen (atau klien) ke elemen independen (atau pemasok). Panah mewakili Ketergantungan yang menentukan arah hubungan, bukan arah proses.
Camera
DisplayWindow <
> {password}
Gambar 6.22 : Dependency
Analisis Paket o Beberapa model analisis (use-case, class analisis) dikategorisasi dalam sebuah pola yang mempaketkan mereka dalam kelompok o Tanda plus di dalam nama class analisis dalam setiap paket menandakan bahwa class-class tersebut mempunyai visibilitas publik dan karena itu dapat diakses dari paket lain. o Simbol lain dapat mendahului elemen di dalam paket. Tanda minus menandakan bahwa elemen disembunyikan dari semua paket, dan tanda # menandakan bahwa elemen hanya dapat diakses oleh paket yang berada di dalam paket tersebut. Contoh gambar analisis paket
package name
Environment +Tree +Landscape +Road +Wall +Bridge +Building +VisualEffect +Scene
Charact ers +Player +Protagonist +Antagonist +SupportingRole
RulesOf TheGame +RulesOfMovement +ConstraintsOnAction
Gambar 8.23. : Analisis Paket Pemodelan Perilaku Model perilaku menggambarkan bagaimana PL merespon event atau stimulan eksternal. Untuk model tersebut, analis harus melakukan langkah-langkah berikut : o Evaluasi semua use-case untuk mendapatkan pemahaman menyeluruh tentang urutan interaksi di dalam sistem. o Mengenali event yang mengendalikan urutan interaksi dan memahamibagaimana event mempunyai relasi terhadap objek spesifik. o Membuat urutan untuk setiap use-case. o Membangun state diagram untuk sistem. o Review model behavioral untuk memverifikasi akurasi dan konsistensi Representasi Keadaan Dalam konteks pemodelan perilaku, dua karakter keadaan harus diperhatikan : o Keadaan setiap class ketika sistem menjalankan fungsinya, dan o Keadaan sistem ketika diobservasi dari luar sebagaimana sistem menjalankan fungsinya. Keadaan class mengambil baik karakter aktif maupun pasif [CHA93]. o Sebuah keadaan pasif adalah status saat ini dari semua atribut objek. o Keadaan aktif dari sebuah objek menggambarkan status saat ini pada objek tersebut ketika menjalankan transformasi atau proses. State diagram control panel class t imer < lockedTime
t imer > lockedTime
locked
password = incorrect & numberOfTries < maxTries comparing
reading
numberOfTries > maxTries
key hit password ent ered
do: validat ePassw ord
password = correct
select ing
act iv at ion successful
Gambar 8.24. : Diagram Control Panel Class Keadaan-keadaan system state—sekumpulan keadaan terobservasi yang menggambarkan perilaku sistem pada satu waktu
state transition—perubahan dari satu keadaan ke keadaan yang lain event—sebuah kejadian yang menyebabkan sistem melakukan perilaku yang sudah diprediksi sebelumnya action—proses yang terjadi sebagai konsekuensi membuat transisi Pemodelan perilaku Membuat daftar keadaan sistem yang berbeda (Bagaimana perilaku sistem ?) Menggambarkan bagaimana sistem membuat transisi dari satu keadaan ke keadaan yang lain.indicate how the system makes a transition from one state to another (Bagaimana sistem mengubah keadaan?) o mengenali event o Mengawali action Menggambar sebuah state diagram atau sequence diagram Sequence Diagram Sebuah diagram sequence adalah jenis diagram interaksi yang menunjukkan bagaimana proses beroperasi dengan satu sama lain dan dalam rangka apa. Ini adalah konstruk Pesan Urutan Chart. Sebuah diagram urutan menunjukkan interaksi objek diatur dalam urutan waktu. Ini menggambarkan objek dan kelas yang terlibat dalam skenario dan urutan pesan yang dipertukarkan antara objek yang dibutuhkan untuk melaksanakan fungsi skenario. Sequence diagram biasanya terkait dengan penggunaan realisasi kasus di View logis dari sistem dalam pengembangan. Sequence diagram kadang-kadang disebut diagram acara, skenario acara, dan diagram waktu. Urutan diagram menunjukkan, sebagai garis vertikal paralel (bertahan hidup), proses yang berbeda atau benda yang hidup bersamaan, dan, sebagai panah horizontal, pesan yang dipertukarkan di antara mereka, dalam urutan di mana mereka terjadi. Hal ini memungkinkan spesifikasi skenario runtime sederhana secara grafis.
co n t ro l p an el
h o meo w n er
syst em read y
sen senso sors rs
syst em
read in g
A p assw o rd en t ered
req u est lo o ku p co mp arin g resu lt password = correct
req u est act ivat io n
num berOf Tries > m axTries
lo cked
A
t imer > lo cked Time
select in g act ivat io n su ccessfu l
Figure 8 .2 7 Sequence diagram (part ial) f or
act ivat io n su ccessfu l
Saf eHome securit y f unct ion
Gambar : 8.25. Sequence Diagram
Menulis spesifikasi perangkat lunak Setiap orang harus tahu pasti apa yang harus dilakukan hingga seseorang menuliskannya !
TUGAS Buatlah sebuah paper yang menjelaskan tentang UML beserta contoh kasusnya, minimal 15 halaman, spasi 1.5, kertas Quarto, sampul mika biru tua. Kriteria penilaian : Validitas/kebenaran Kelengkapan Kompleksitas kasus
