Disusun Oleh: Defri Kurniawan, M.Kom Teknik Informatika UDINUS

Slides:



Advertisements
Presentasi serupa
U M L Unified Modeling Language
Advertisements

PEMODELAN ANALISIS Kuliah - 5
Ian Sommerville Software Engineering
BPR – Tahap 1 (Persiapan)
Pertemuan 8 Proyek Sistem Informasi Viska Armalina, ST., M.Eng
ANALISIS DAN PERANCANGAN SISTEM
PENGENALAN ANALISA SISTEM BERORIENTASI OBYEK
Pertemuan 6 Structural modelling
BY DR. HERI NUGRAHA. SE.MSi
Architecture dan design
Fase Analisa Sistem Menggambarkan kebutuhan sistem
Analisis Model.
Pertemuan 1 Konsep Dasar OOAD
Rekayasa Perangkat Lunak Proses Rekayasa Perangkat Lunak
Keuntungan metodologi berorientasi objek.
Activity Diagram Shinta P.. For Bussiness Modeling, Activity diagrams describe the activities of a class. It is used for the following purposes: (Bennet.
Model dan Pemodelan. Topik Bahasan 1. Definisi Model dan Pemodelan 2. Beberapa jenis model 3. Model pada Pengembangan Sistem.
Summary Materi RPL Mid Semester
Analisis Kebutuhan Software
Chapter 3 Specification of Requirements Models. 3.1 Introduction Sistem berbasis komputer mengintegrasikan, pengolahan informasi sub-sistem, satu atau.
Rekayasa Perangkat Lunak UML (Unified Modelling Language)
Analisa dan Perancangan Berbasis Objek
Visual Modelling Teguh Sutanto, S.Kom.,M.Kom.
Analisis Model.
Specification of Requirement Model Bab - 3
Review Rekayasa Perangkat Lunak
Object oriented analyst and design
Object oriented analyst and design
Perancangan Sistem Informasi
Analisa dan Desain Berorientasi Obyek
Object-Oriented Analysis (OOA)
PENGEMBANGAN PERANCANGAN SISTEM
PERANCANGAN SISTEM BERORIENTASI OBJEK DENGAN UML
Object oriented analyst and design
Rekayasa Perangkat Lunak
KEBUTUHAN & SPESIFIKASI SOFTWARE
Model Konvensional.
REKAYASA PERANGKAT LUNAK (IF 1483)
PEMODELAN PROYEK (UML)
Disusun Oleh: Defri Kurniawan, M.Kom Teknik Informatika UDINUS
Disusun Oleh: Defri Kurniawan, M.Kom Teknik Informatika UDINUS
REKAYASA PERANGKAT LUNAK
Rekayasa Perangkat Lunak Pertemuan 7
PEMODELAN SISTEM METODE TERSTRUKTUR
PEMODELAN OBJECT ORIENTED
REKAYASA PERANGKAT LUNAK
Model dan Pemodelan Analisa Desain Berorientasi Objek
Review Rekayasa Perangkat Lunak
Oleh : Sri Herawati, S.Kom, M.Kom
KEBUTUHAN & SPESIFIKASI SOFTWARE
Analisa [Kebutuhan] Sistem
UNIFIED MODELLING LANGUAGE
REKAYASA PERANGKAT LUNAK
Analisis Model.
Oleh : Sri Herawati, S.Kom
ANALISIS & DESAIN SISTEM
Review Rekayasa Perangkat Lunak
Review Rekayasa Perangkat Lunak
KELOMPOK 6 Modeling Adnin Devit C F
Perancangan Berorientasi Objek
Pertemuan 8 RPL Oleh : Syukriya al-Asyik S.Kom
Pertemuan 9 UML Diagram Class & Diagram Objek
Pemodelan Sistem PL.
Pertemuan 6 Unified Modeling Language (UML)
KEBUTUHAN & SPESIFIKASI SOFTWARE
Rekayasa Perangkat Lunak
Model Struktural dan Model Perilaku
OBJECT ORIENTED ANALISYS AND DESIGN
TIM RPL Program Studi Teknik Informatika
Object oriented analyst and design
Transcript presentasi:

Disusun Oleh: Defri Kurniawan, M.Kom Teknik Informatika UDINUS Teknik Informatika S1 Software Requirement Engineering Specification of Requirements Models Disusun Oleh: Defri Kurniawan, M.Kom Teknik Informatika UDINUS

SILABUS MATA KULIAH 1. Requirement Engineering 2. Requirement Elicitation 3. Specification of Requirement Models 4. Requirement Prioritization 5. Requirement Interdependencies: State of the Art and Future 6. Impact Analysis 7. Requirement Negotiation 8. Quality Assurance in Requirement Engineering

Specification of Requirements Models Introduction specification of Requirements Models Modeling vs. Specification Meta-Models Categories Specification Methodology Requirements Transformation

Comparison of Techniques and Approaches Interviews Domain Group work Ethnography Prototyping Goals Scenarios Viewpoints Understanding the domain X Identifying sources of requirements Analyzing the stakeholders Selecting techniques and approaches Eliciting the Requirements

Methodology Berdasarkan Requirements Elicitation ? Ini terdiri dari kumpulan teknik seperti Data Flow Diagram (DFD) yang detail dekomposisi fungsional dengan penekanan pada data masuk dan keluar dari sistem dan komponen terkait. Entity Relationship Diagram (ERD) yang memfasilitasi representasi entitas sistem, atribut mereka, dan hubungan mereka satu sama lain

Methodology Based Requirements Elicitation Structured Analysis and Design (SAD) Object Oriented (OO) Approaches Ini terdiri dari kumpulan teknik seperti Data Flow Diagram (DFD) yang detail dekomposisi fungsional dengan penekanan pada data masuk dan keluar dari sistem dan komponen terkait. Entity Relationship Diagram (ERD) yang memfasilitasi representasi entitas sistem, atribut mereka, dan hubungan mereka satu sama lain

Methodology Based Requirements Elicitation 1. Structured Analysis and Design (SAD) Terdiri dari kumpulan teknik seperti Data Flow Diagram (DFD) dengan detail dekomposisi fungsional yang menekankan pada data masuk dan keluar dari sistem dan komponen terkait. Entity Relationship Diagram (ERD) yang memfasilitasi representasi entitas sistem, atribut mereka, dan hubungan mereka satu sama lain Ini terdiri dari kumpulan teknik seperti Data Flow Diagram (DFD) yang detail dekomposisi fungsional dengan penekanan pada data masuk dan keluar dari sistem dan komponen terkait. Entity Relationship Diagram (ERD) yang memfasilitasi representasi entitas sistem, atribut mereka, dan hubungan mereka satu sama lain

Methodology Based Requirements Elicitation 2. Object Oriented (OO) Approaches Khususnya Unified Modeling Language (UML) berisi beberapa teknik yang sering digunakan untuk elisitasi kebutuhan yang ditetapkan dengan notasi namun fleksibel dan format seperti Use Case diagrams, Use Case descriptions, and Class Diagrams. Khususnya Unified Modeling Language (UML) berisi beberapa teknik yang sering digunakan untuk elisitasi persyaratan yang ditetapkan dengan notasi namun fleksibel dan format seperti Use case diagram, deskripsi Use Case, dan Class Diagram.

Introduction Tujuan utama dari bab ini adalah: Untuk mempresentasikan dan mendiskusikan satu set model dan teknik spesifikasi, dalam apa yang menyangkut ontologi (Studi yang membahas keberadaan sesuatu yang bersifat konkret) dan dukungan mereka dalam representasi kebutuhan dari sistem berbasis komputer.

Modeling vs. Specification Keputusan pertama pengembang ketika mereka ingin menentukan (specify) sebuah sistem adalah untuk memilih bagian mana dari sistem yang mereka ingin pertimbangkan. Pemilihan bagian mendefinisikan tampilan sistem (system view), yaitu perspektif sistem yang harus diwakili

Specification of Systems

Specification of Systems Formalisasi tampilan sistem (system view) terjadi ketika berasal dari model. Model ini terdiri dalam suatu representasi (masih konseptual) berdasarkan pandangan sistem menurut sebuah meta-model tertentu.

Specification of Systems Meta-model ini sesuai dengan sekumpulan elemen komposisi (fungsional atau struktural) dan aturan komposisi yang memungkinkan untuk membangun sebuah model yang mewakili pandangan sistem.

Modeling vs. Specification ?

Modeling vs. Specification Perbedaan antara modeling dan spesifikasi: Modeling sesuai dengan aktivitas memilih meta-model untuk meresmikan pada tingkat konseptual / tampilan sistem tertentu, sedangkan Spesifikasi berkaitan dengan penerapan bahasa untuk membuat model sistem nyata.

Meta Model?

Meta-Models Meta yang diambil dari bahasa yunani yang berarti Beyond/ Melampaui/Atas, dan  Model yang menjelaskan model dunia seseorang. Meta Model adalah suatu perangkat alat komunikasi untuk membuat orang me-modelkan lebih luas dari dunia yang ada sekarang. Contohnya: Setiap orang pasti ingin sukses dan berhasil, tetapi model dunianya berkata sebaliknya, seperti : “Saya tidak pandai dalam bisnis” / “Saya selalu gagal dalam bisnis”. Ketika ini terjadi, maka bisa dibayangkan untuk mencapai tujuannya menjadi sebuah kesulitan tersendiri.

Meta-Models Categories Idealnya, bahasa representasi harus memungkinkan spesifikasi karakteristik sistem yang diinginkan, dalam cara yang tidak ambigu. Syarat bahasa meta-model harus: Formal (akurat, ketat), untuk menghindari ambiguitas dalam penafsiran representasi sistem. Lengkap, untuk memungkinkan pembangunan representasi yang benar-benar menggambarkan tampilan sistem.

Meta-Models Categories State Oriented Meta-Models Activity Oriented Meta-Models Structure Oriented Meta-Models Data Oriented Meta-Models Heterogeneous Meta-Models Multiple View Approach

Meta-Models Categories 1. State Oriented Meta-Models State oriented meta-models memungkinkan pemodelan sistem sebagai set of states dan satu set transisi. Transisi antar states menurut beberapa stimulus (rangsangan) eksternal. Meta-model yang memadai untuk model sistem di mana perilaku jasmani adalah aspek yang paling penting untuk ditangkap Berorientasi Negara meta-model memungkinkan pemodelan sistem sebagai seperangkat negara bagian dan satu set transisi. Transisi antara negara-negara berkembang menurut beberapa stimulus eksternal. Ini meta-model yang memadai untuk model sistem di mana perilaku jasmani adalah aspek yang paling penting untuk ditangkap

Meta-Models Categories 1. State Oriented Meta-Models Contoh: * Finite State Machines (FSMs), * Finite State Machines with Data paths (FSMDs), * State Charts * Petri nets

Meta-Models Categories 2. Activity Oriented Meta-Models Meta-models berorientasi aktivitas memungkinkan pemodelan sistem sebagai serangkaian kegiatan yang berkaitan dengan data atau dengan eksekusi yang berkaitan. Meta-models ini sangat cocok untuk model sistem dimana data dipengaruhi oleh urutan transformasi dengan laju yang konstan. Berorientasi aktivitas meta-model memungkinkan pemodelan sistem sebagai serangkaian kegiatan yang berkaitan dengan data atau dengan eksekusi dependensi. Ini meta-model sangat cocok untuk model sistem dimana data dipengaruhi oleh urutan transformasi dengan laju yang konstan

Meta-Models Categories 2. Activity Oriented Meta-Models Contoh: * Data Flow Diagram (DFD) * Flowcharts

Meta-Models Categories 3. Structured Oriented Meta-Models Structured oriented meta-models memungkinkan deskripsi sistem modul fisik dan interkoneksi mereka. Meta-model yang didedikasikan untuk karakterisasi komposisi fisik dari suatu sistem, bukan fungsinya. memungkinkan deskripsi sistem modul fisik dan interkoneksi mereka. Ini meta-model yang didedikasikan untuk karakterisasi komposisi fisik dari suatu sistem, bukan fungsinya.

Meta-Models Categories 3. Structured Oriented Meta-Models Contoh: * Block Diagram/ Component-Connectivity Diagrams (CCDs) UML’s deployment dan component diagram didasarkan pada meta-model ini.

Meta-Models Categories 4. Data Oriented Meta-Models Data oriented meta-models memungkinkan pemodelan sistem sebagai kumpulan data yang berhubungan dengan beberapa jenis atribut. Meta-models ini mendedikasikan organisasi data lebih penting daripada fungsi sistem. memungkinkan pemodelan sistem sebagai kumpulan data yang berhubungan dengan beberapa jenis atribut. Ini meta-model mendedikasikan lebih penting untuk organisasi data daripada fungsi sistem.

Meta-Models Categories 4. Data Oriented Meta-Models Data oriented meta-models, biasanya digunakan dalam metodologi berdasarkan analisis struktur tradisional dan teknik desain.

Meta-Models Categories 4. Data Oriented Meta-Models Contoh: Entity Relationship Diagram (ERD) Jackson’s structured diagrams (JSDs)

Meta-Models Categories 5. Heterogeneous Meta-Models Heterogeneous meta-models memungkinkan penggunaan dalam representasi sistem yang sama, beberapa karakteristik dari meta-model yang berbeda, yaitu empat kategori yang dijelaskan sebelumnya. Meta-models ini adalah solusi yang baik ketika sistem yang relatif kompleks harus dimodelkan. memungkinkan penggunaan, dalam representasi sistem yang sama, beberapa karakteristik dari meta-model yang berbeda, yaitu empat kategori yang dijelaskan sebelumnya Ini meta-model solusi yang baik ketika sistem yang relatif kompleks harus dimodelkan

Meta-Models Categories 5. Heterogeneous Meta-Models Contoh: Control/ Data Flow Graphs (CDFGs) Object Process Diagram (OPDs) Program State Machines (PSMs)

Meta-Models Categories 6. Multiple-View Approach Dengan meningkatnya kompleksitas sistem, penggunaan meta-model yang berbeda untuk mewakili berbagai jenis karakteristik sistem menjadi hal yang umum. Multiple view approach bisa digunakan sesuai dengan kompleksitas sistem yang semakin berkembang.

Specification Methodology Three Key Issues: Specification Language Complexity Control Model Continuity

Specification Language Bahasa spesifikasi harus memungkinkan representasi dari pandangan sistem tertentu, tanpa ambiguitas. Ini adalah tujuan utama dari bahasa spesifikasi.

Complexity Control Kontrol dari kompleksitas proses spesifikasi dapat dilakukan dalam dua dimensi yang berbeda: Representational complexity dan Development complexity

Complexity Control Representational complexity Pada dasarnya tergantung pada bahasa spesifikasi, dan jika dikelola dengan benar memungkinkan diperoleh spesifikasi yang ringkas dan mudah dipahami. Pendekatan grafis biasanya lebih mudah dipahami daripada yang tekstual. Dengan demikian meningkatkan pembacaan dan understandability pandangan sistem. UML mengadopsi pendekatan grafis.

Complexity Control 2. Development complexity Dimensi kedua kontrol kompleksitas (development complexity) mengacu pada kontrol dari evolusi spesifikasi sistem dari konseptualisasi awal kebutuhan.

Model Continuity

Requirements Transformation User Requirements Modeling Identifikasi komponen sistem membutuhkan definisi model untuk menangkap fungsionalitas sistem yang ditawarkan untuk para penggunanya. Use Case adalah salah satu teknik yang paling cocok untuk tujuan itu, karena sederhana dan mudah dibaca. The identification of the system components requires the definition of a model to capture the system functionalities offered to its users. Use cases are one of the most suitable techniques for that purpose, since they are simple and easy to read.

Requirements Transformation User Requirements Modeling Dalam faktanya, Use Case hanya terdiri dari 3 konsep utama: 1. Use cases 2. Actors, and 3. Relationships

Requirements Transformation User Requirements Modeling UML top level use case diagram according two criteria: Functionality Criteria

Requirements Transformation User Requirements Modeling UML top level use case diagram according two criteria: Domain Criteria

Requirements Transformation 4SRS Technique Transforming use case into architectural models representing system requirements is a difficult task A technique called 4 step rule set 4SRS: Object creation (step 1) Object elimination (step 2) Object packaging and aggregation (step 3) and Object association (step 4) Transforming use case into architectural models representing system requirements is a difficult task A technique called 4 step rule set 4SRS The 4SRS is organized as four steps to transform use case into objects: Object creation (step 1), Object elimination (step 2), Object packaging and aggregation (step 3) and Object association (step 4)

Requirements Transformation 4SRS Technique Step 1 – Object creation Setiap use case harus ditransformasikan ke dalam 3 objek (One interfaces, one data, and one control) Step 2 – Object elimination Ini harus diputuskan mana dari tiga obyek harus dijaga untuk sepenuhnya mewakili dengan mempertimbangkan seluruh sistem Step 1 – Object creation Each use case must be transformed into three objects (One interfaces, one data, and one control) Step 2 – Object elimination It must be decided which of the three objects must be maintained to fully represent, in computational terms, the use case, taking into account the whole system and not each use case in isolation

Requirements Transformation 4SRS Technique Step 3 – Object packaging and aggregation Objek yang tersisa (dari step 2) yang ada keuntungan dalam diperlakukan dengan cara yang terpadu harus memberikan asal ke agregasi atau paket objek yang konsisten

Requirements Transformation 4SRS Technique Step 4 – Object association Mendukung asosiasi di dalam model objek

TERIMA KASIH