Analisis Kebutuhan Analisis Kebutuhan Menentukan karakteristik operasional PL Menunjukkan antarmuka PL dengan elemen sistem yang lain Membuat batasan yang harus dipenuhi PL Analisis Kebutuhan memungkinkan Software Engineer (disebut analis atau modeler) untuk : Memperinci kebutuhan dasar yang dibuat kapda rekayasa kebutuhan sebelumnya Membangun model yang dapat menggambarkan skenario user, aktivitas fungsional, class masalah dan relasinya, sistem dan perilaku class, dan aliran data ketika ditransformasikan.

Sebuah Jembatan

Transformasi Analisi Model ke Design Model terstruktur (Konvensional) Konvensional menggunakan tools DFD/DAD dan menekankan pada proses. Maksudnya sistem dianggap terdiri dari proses-proses.

Transformasi Analisi Model ke Design Model berorientasi objek (Object Oriented) Orientasi Objek menggunakan tools UML dan menekankan pada objek/modul. Maksudnya sistem dianggap terdiri dari objek-objek.

Aturan-Aturan Model harus fokus pada masalah atau domain bisnis. Tingkat abstraksinya relatif harus lebih tinggi. Setiap elemen model analisis sebaiknya memberikan tambahan pada pemahaman keseluruhan kebutuhan PL dan menyediakan wawasan pada domain informasi, fungsi dan perilaku sistem. Tunda semua konsideran infrastruktur dan model non fungsional hingga fase desain. Minimalisasi rangkaian melalui sistem. Pastikan model analisis menyediakan nilai untuk semua stakeholder. Jaga model sesederhana mungkin.

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

Analisis Domain Tentukan domain yang ingin diinvestigasi. Kumpulkan contoh representatif aplikasi pada domain tersebut. Analisis setiap aplikasi pada contoh. Kembangkan model analisis untuk objek.

Pemodelan Data 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

What is a Data Object? Object —Sesuatu yang dijelaskan oleh satu set Attribut (item data) dan yang akan Dimanipulasi dalam perangkat lunak (sistem) Masing-masing instance dari objek (misalnya, buku) Dapat diidentifikasi secara unik(misalnya, ISBN #) Masing-masing memainkan peran penting dlm sistem) Yaitu, sistem tidak berfungsi tanpa Akses ke instance object Masing-masing digambarkan oleh attribut yang Yang berada pada item data

Objek-Objek Umum Entitas eksternal (printer, user, sensor) Sesuatu (laporan, display, sinyal) Kejadian atau event (interupsi, alarm) orang (manager, engineer, salesperson) Unit organisasi (divisi, tim) tempat (lantai pabrik) struktur (employee record)

Objek Data dan Atribut Sebuah objek data terdiri dari sekumpulan atribut yang bertindak sebagai aspek, kualitas, karakteristik, atau penjelas objek object: automobile attributes: make model body type price options code

Apakah Relationship? Relationship – menandakan kaitan, sebuah fakta yang harus diingat oleh sistem, tidak dikomputasi atau diturunkan secara mekanis several instances of a relationship can exist objects can be related in many different ways

Notasi ERD Satu bentuk umum: object object Bentuk Umum yang lain: relationship object 1 2 (1, 1) attribute Bentuk Umum yang lain: object relationship object 1 2 (0, m) (1, 1)

Membangun Sebuah ERD Level 1—modelkan semua objek data (entitas) dan koneksinya dengan yang lain Level 2—modelkan semua entitas dan relasi Level 3—modelkan semua entitas, relasi, dan atribut yang menyediakan informasi yang lebih mendalam

ERD: sebuah contoh request Customer for service (1,1) (1,m) (1,1) places (1,1) (1,m) (1,1) standard task table (1,n) work order generates (1,1) (1,1) (1,1) selected from work tasks (1,w) consists of (1,w) (1,i) materials lists

Konsep Object-Oriented Harus dipahami untuk menerapkan elemen berbasis class pada model analisis Konsep-konsep kunci: Classes dan objects Attributes dan operations Encapsulation dan instantiation 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

Membangun Class

Apakah Class? occurrences roles organizational units things places external entities structures class name attributes: operations:

Enkapuslasi/Penyembunyian Objek mengenkapsulasi Baik data dan prosedur Logis yang dibutuhkan Untuk manipulasi data method # 1 method # 2 data method # 3 method # 6 method # 5 method # 4 Achieves “information hiding”

Hierarki Class PieceOfFurniture (superclass) Table Chair Desk ”Chable" subclasses of the instances of Chair

Method (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?

Use-Cases 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

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

Swimlane Diagrams 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

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 computer based system input output

Notasi Model Aliran Entitas Eksternal proses Aliran data Penyimpanan data

Entitas Eksternal Produsen atau konsumen sebuah data Contoh : seseorang, piranti, sensor Contoh lain : sistem berbasis komputer Data harus selalu berawal dari suatu tempat dan Harus selalu dikirim pada sesuatu

Proses Sebuah transformer data (mengubah input menjadi output) Contoh: menghitung pajak, menentukan luas, Memformat laporan, menampilkan grafik Data harus selalu diproses dalam bentuk tertentu Untuk menerima fungsi sistem

Aliran Data Data mengalir melalui sebuah sistem dimulai Sebagai input dan ditransformasi menjadi output base compute triangle area area height

Menyimpan Data Data disimpan untuk digunakan lagi. look-up sensor data sensor #, type, location, age look-up sensor data report required type, location, age sensor number sensor data

Petunjuk menggambar DFD Semua icon harus diberi nama yang bermakna jelas DFD berkembang dalam beberapa tingkatan Selalu dimulai dengan sebuah context level diagram (level 0) Selalu menunjukkan entitas eksternal pada level 0 Selalu berinama panah aliran data Jangan menampilkan prosedur logika

Membangun sebuah DFD—I Mereview model data untuk mengisolasi objek data dan gunakan parsing gramatikal untuk menentukan “Operasi” Menentukan entitas eksternal (produsen dan konsumen data) Membuat level 0 DFD

Contoh Level 0 DFD user digital video monitor processor video source processing request user requested video signal digital video processor monitor video source NTSC video signal

Membangun DFD—II Tulis sebuah narasi yang menggambarkan transformasi Parsing untuk menentukan transformasi tingkat berikutnya “seimbangkan” aliran untuk menjaga aliran data Bangun level 1 DFD Gunakan rasio 1:5 (perkiraan)

Hierarki Aliran Datang b x P y level 0 c a p2 f p1 b p4 d 5 g p3 e level 1

Catatan untuk DFD Setiap lingkaran harus dipecah hingga dia hanya melakukan hanya SATU hal Rasio ekspansi menurun sesuai dengan jumlah level yang meningkat Kebanyakan sistem membutuhkan antara 3 hingga level 7 untuk model aliran yang cukup. Sebuah item aliran data (panah) dapat dikembangkan seiring dengan meningkatnya level (data dictionary menyediakan informasi ini)

Spesifikasi Proses (PSPEC) Lingkaran PSPEC naratif pseudocode (PDL) persamaan tabel Diagram dan atau grafik

Setelah DFD? analysis model Maps into design model

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

Control Flow Diagram

Control Specification (CSPEC) CSPEC dapat berupa: state diagram (sequential spec) state transition table combinatorial spec decision tables activation tables

Panduan Membangun CSPEC Lihat semua sensor yang “dibaca” oleh PL Lihat semua kondisi interupsi Lihat semua "switches" yang diaktifkan oleh operator Lihat semua kondisi data Melihat parsing kata benda/kerja yang diterapkan pada Statemen software atau lingkupnya, mereview semua item kendali Sebagai input/output CSPEC yang mungkin Menggambarkan perilaku sebuah sistem dengan identifikasi Keadaan; menentukan bagaimana setiap keadaan 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 to 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

Class Analisis 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 atribut Atribut umum Operasi umum Kebutuhan esensial

Class Diagram Class name attributes operations

Class Diagram

Pemodelan CRC Class-class analisis memiliki “tanggung-jawab” Tanggungjawab adalah atribut-atribut dan operasi-operasi yang terenkapsulasi oleh class Class-class analisis berkolaborasi satu dengan yang lain Collaborators adalah class-class yang dibutuhkan untuk menyediakan sebuah class dengan informasi yang dibutuhkan untuk memenuhi tanggung jawabnya. Secara umum, sebuah kolaborasi berakibat permintaan informasi atau permintaan beberapa aksi/operasi.

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 : Pembuatan atau update objek entitas; Inisiasi objek perbatasan sebagaimana mereka mendapatkan informasi dari objek entitas; Komunikasi kompleks antara sekumpulan objek; Validasi data yang dikomunikasikan antara user dan aplikasi.

Responsibilities System intelligence should be distributed across classes to best address the needs of the problem Each responsibility should be stated as generally as possible Information and the behavior related to it should reside within the same class Information about one thing should be localized with a single class, not distributed across multiple classes. Responsibilities should be shared among related classes, when appropriate.

Kolaborasi Class memenuhi tanggung jawabnya dengan satu diantara dua cara : Sebuah class dapat menggunakan operasinya sendiri untuk memanipulasi atributnya masing-masing atau 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]: is-part-of relationship has-knowledge-of relationship depends-upon relationship

Composite Aggregate Class

Review model CRC Semua peserta dalam review (model CRC) diberikan sebuah subset dari kartu index model CRC. 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. 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. 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. 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 Dalam UML relasi ini sering disebut asosiasi Asosiasi dapat didapatkan dengan mengenali multiplicity (istilah cardinality digunaikan dalam pemodelan data Dalam banyak instans, relasi client-server ada diantara dua class analisis. Dalam kasus ini, class client tergantung pada class server dalam suatu cara dan relasi dependensi terjadi

Multiplicity

Dependencies

Analisis Paket Beberapa model analisis (use-case, class analisis) dikategorisasi dalam sebuah pola yang mempaketkan mereka dalam kelompok 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. 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.

Analysis Packages

Pemodelan Perilaku Model perilaku menggambarkan bagaimana PL merespon event atau stimulan eksternal. Untuk model tersebut, analis harus melakukan langkah-langkah berikut : Evaluasi semua use-case untuk mendapatkan pemahaman menyeluruh tentang urutan interaksi di dalam sistem. Mengenali event yang mengendalikan urutan interaksi dan memahamibagaimana event mempunyai relasi terhadap objek spesifik. Membuat urutan untuk setiap use-case. Membangun state diagram untuk sistem. Review model behavioral untuk memverifikasi akurasi dan konsistensi

Representasi Keadaan Dalam konteks pemodelan perilaku, dua karakter keadaan harus diperhatikan : Keadaan setiap class ketika sistem menjalankan fungsinya, dan Keadaan sistem ketika diobservasi dari luar sebagaimana sistem menjalankan fungsinya. Keadaan class mengambil baik karakter aktif maupun pasif [CHA93]. Sebuah keadaan pasif adalah status saat ini dari semua atribut objek. Keadaan aktif dari sebuah objek menggambarkan status saat ini pada objek tersebut ketika menjalankan transformasi atau proses.

State Diagram for the ControlPanel Class

Keadaan-Keadaan Sistem 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?) mengenali event Mengawali action Menggambar sebuah state diagram atau sequence diagram

Sequence Diagram

Menulis Spesifikasi PL 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

Panduan Spesifikasi

Panduan Spesifikasi

Panduan Spesifikasi