Bab 6. Rekayasa Sistem. Rekayasa Sistem Komputer (Computer system engineering) terdiri atas 2 bagian, yaitu :

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.

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

INPUT OUTPUT DATABASE PROCEDURE HARDWARE SOFTWARE PEOPLE DOCUMENT SYSTEM

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

o Tujuan strategis ditentukan

o Faktor sukses/aturan bisnis ditentukan o Model perusahaan dibuat

 Business area analysis (BAA) o Proses/layanan dimodelkan o Inter-relasi proses dan data  Application Engineering

o RPL

o Pemodelan aplikasi/prosedur yang merujuk pada BAA dan batasan-batasan ISP

 Construction and delivery

o menggunakan CASE dan 4GTs, pengujian

Didalam melakukan informationa strategy planning (ISP) diperlukan informasi isu-isu seperti :

 Isu manajemen

o Menentukan tujuan bisnis strategis o Isolasi critical success factors

o Melakukan analisis pada pengaruh teknologi o Melakukan analisis pada sistem strategis  Isu teknis

o Membuat model data tingkat tertinggi

o Dikelompokkan berdasar area bisnis/organisasi o 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

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

Rekayasa Produk

Gambar 6.4. : Rekayasa Produk 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.

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

CLSS processor

Sort ing subsyst em

Sensor dat a acquisit ion subsyst em

Operat or display

shunt cont roller

Conveyor

Pulse t ach Bar code reader

Shunt act uat or

g e t c o n v e y o r sp e e d 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 re a d b a r c o d e st a rt c o n v e y o r l i n e d e t e r m i n e b i n l o c a t i o n v alid bar c ode

se t f o r re j e c t b i n c onv ey or in m ot ion re a d b a r c o d e g e t c o n v e y o r st a t u s p ro d u c e re p o rt e n t ry c onv ey or s t opped inv alid bar c ode

Gambar 6.8. : Diagram Activity Class Diagram

Class Diagram adalah diagram statis. Ini merupakan pandangan statis dari sebuah aplikasi. Diagram kelas tidak hanya digunakan untuk memvisualisasikan, menggambarkan dan mendokumentasikan aspek yang berbeda dari sistem tetapi juga untuk membangun kode dieksekusi dari aplikasi 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.

Gambar 6.9. : Class Diagram 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( ) class name 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)

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.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 "menang-menang"

Kebutuhan Validasi

1. Apakah setiap persyaratan yang konsisten dengan tujuan sistem?

2. Apakah semua persyaratan telah ditetapkan pada tingkat abstraksi yang tepat? 3. Apakah persyaratan yang benar-benar diperlukan?

4. Apakah kebutuhan masing-masing dibatasi dan tidak ambigu? 5. Apakah kebutuhan masing-masing memiliki atribusi?

6. Apakah ada konflik dengan persyaratan persyaratan lainnya?

7. Apakah kebutuhan masing-masing dicapai dalam lingkungan teknis sistem? 8. Apakah setiap kebutuhan dapat diuji, sekali diterapkan?

9. Apakah model mencerminkan sistem informasi, fungsi dan perilaku? 10. Apakah model telah tepat "dipartisi"?

11. Apakah 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

Gambar 8.1.: Jembatan yang menghubungkan deskripsi system, model analisis dan model desain system description analysis model design model

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 Memeriksa objek data secara independen terhadap proses o Fokus perhatikan pada domain data

o Membuat sebuah model pada abstraksi level konsumen

o 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

Gambar 8.3.: ERD Rumah Sakit

sumber : http://www.smartdraw.com/resources/glossary/entity-relationship-diagram/

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

Gambar : 8.5. Proses Class

Enkapsulisasi (Penyembunyian)

Objek mengenkapsulasi baik data dan prosedur logis yang dibutuhkan untuk manipulasi data external entities things occurrences _roles organizational units places structures class name a op

Gambar 8.6.: Penyembunyian informasi

Hierarkhi Class

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

method # 1 data method # 2 method # 4 method # 5 method # 6 method # 3 Chair

Table Desk ”Chable"

instances of Chair

PieceOfFurniture (superclass)

 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

Gambar 8.8. : Diagram Use Case homeowner

Access camera surveillance via t he

Int ernet

Conf igure Saf eHome syst em paramet ers

Set alarm

cameras

Diagram aktifitas :

Melengkapi use-case dengan menyediakan representasi diagram dari aliran prosedural.

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

ent er password and user ID

selec t major f unc t ion

valid passwor ds/ ID

prompt f or reent ry

invalid passwor ds/ ID

input t r ies r em ain no input

t r ies r em ain

selec t surv eillanc e

ot her f unct ions m ay also be

select ed

t hum bnail views select a specif ic cam er a

selec t c amera ic on

prompt f or anot her v iew selec t spec if ic c amera - t humbnails

exit t his f unct ion _{see anot her cam er a}

v iew c amera out put in labelled window

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

ent er pas s word and us er ID

s elec t m ajor f unc t ion

valid p asswo r d s/ ID prom pt f or reent ry in valid p asswo r d s/ ID in p u t t r ies r em ain n o in p u t t r ies r em ain

s elec t s urv eillanc e

o t h er f u n ct io n s m ay also b e

select ed

t h u m b n ail views select a sp ecif ic cam er a

s elec t c am era ic on

generat e v ideo out put s elec t s pec if ic

c am era - t hum bnails

exit t h is f u n ct io n see an o t h er cam er a h o m e o w n e r c a m e r a i n t e r f a c e prom pt f or anot her v iew v iew c am era out put

Notasi Model Aliran

Gambar 8.11. Notasi dalam diagram ER Menyimpan 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

Data disimpan untuk digunakan lagi.

look-up sensor data sensor # report required sensor #, type, location, age sensor data sensor number type, location, age

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

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

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

user

processing request

video

source _{video signal}NTSC

digital video processor requested video signal monitor

P

a

b

x

y

p1 p2 p3 p4 ₅

a

b

c

d

e

f

g

level 0

level 1

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

Gambar 8.15. : Spesifikasi Proses Setelah melakukan DFD, selanjutnya adalah :

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 PSPEC naratif pseudocode (PDL) persamaan tabel

Diagram dan atau grafik Lingkaran

Maps into

analysis model

• 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

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.

read operator input _manage copying reload process perform problem diagnosis create user displays empty jammed full

display panel enabled beeper on/off

start

problem light copies done

- 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

Gambar 8.18 : Diagram Class

Contoh Class Diagram

Gambar 8.19.: Class Diagram Pemodelan CRC

 Class-class analisis memiliki “tanggung-jawab”

System program() display() reset() query() modify() call() systemID verificationPhoneNumber systemStatus delayTime telephoneNumber masterPassword temporaryPassword numberTries

Class name

attributes

operations

FloorPlan determineType ( ) positionFloorplan scale( ) change color( ) type name outsideDimensions Cam er a

det erm ineTy pe () t rans lat eLoc at ion () dis play ID() dis play V iew() dis play Zoom () t y pe ID loc at ion f ieldV iew panA ngle Zoom Set t ing

WallSegm ent t y pe

s t art Coordinat es s t opCoordinat es nex t WallSem ent

determineType ( ) draw( ) Window t y pe s t art Coordinat es s t opCoordinat es nex t Window determineType ( ) draw( )

is placed wit hin

Wall t y pe wallDim ens ions

determineType ( ) computeDimensions ( ) Door t y pe s t art Coordinat es s t opCoordinat es nex t Door determineType ( ) draw( ) is par t of is used t o build is used t o build is used t o build

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

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 Class: Description: Responsibility: Collaborator: Class: Description: Responsibility: Collaborator: Class: Description: Responsibility: Collaborator: Class: FloorPlan Description: Responsibility: Collaborator:

incorporates walls, doors and windows shows position of video cameras defines floor plan name/type manages floor plan positioning scales floor plan for display scales floor plan for display

Wall Camera

• 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

Gambar 8.20 : Composite Agregate Class Player

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).

Gambar 8.21: Multiplicity

WallSegm ent Window Door

Wall is used to build is used to build is used to build 1..* 1 1 1 0..* 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.

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

Environment +Tree +Landscape +Road +Wall +Bridge +Building +VisualEffect +Scene Charact ers +Player +Protagonist +Antagonist +SupportingRole RulesOf TheGame +RulesOfMovement +ConstraintsOnAction package name Cam era Dis playWindow {password} <<acces s >>

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

Gambar 8.24. : Diagram Control Panel Class Keadaan-keadaan system

 state—sekumpulan keadaan terobservasi yang menggambarkan perilaku sistem pada satu waktu

reading locked select ing password ent ered comparing password = incorrect & numberOf Tries < maxTries

password = correct

act iv at ion successf ul key hit

do: validat ePassw or d

numberOf Tries > maxTries t imer < lockedTime

 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.

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

h o meo w n er co n t ro l p an el syst em sen so rssen so rs

syst em read y read in g req u est lo o ku p co mp arin g resu lt p assw o rd en t ered

pas s word = c orrec t

req u est act ivat io n

act ivat io n su ccessfu l lo cked

num berOf Tries > m ax Tries

select in g t imer > lo cked Time

A A

Figur e 8 .2 7 Sequence diagr am ( par t ial) f or Saf eHome secur it y f unct ion