Catatan Kuliah Rekayasa Perangkat Lunak (Software Engineering) Bagian 2

dokumen-dokumen yang mirip
Mohamad Sidiq Teknik Informatika Fakultas Ilmu Komputer Universitas Dian Nuswantoro1

Kenapa Arsitektur? Tim RPL 1 2

Metode Perancangan. Tahap Perancangan

Adam Hendra Brata Teknik Informatika FILKOM UB Semester Genap 2015/2016

Data & Architecural Design. Tim RPL Progdi Teknik Informatika

BAB 2 PROSES PENGEMBANGAN PIRANTI LUNAK Proses : Pandangan Umum

1. Quick Look of this chapter. 2. Software Architecture. 3. Data Design. 4. Architectural Styles and Patterns. 5. Architectural Design

Software Design. Konsep dan Prinsip Desain Struktur Desain. Mira/Rpl/Design

Bab 9. Rekayasa Desain

Analisis Model Perangkat Lunak

Pertemuan 9 PRINSIP DAN KONSEP DESAIN

Review Rekayasa Perangkat Lunak. Nisa ul Hafidhoh

Pertemuan 10 METODE DESAIN (1)

Analysis Modeling 4/10/2018. Focus on What not How. Kenapa Analisis Kebutuhan. Definisi Analisis Kebutuhan. Langkah-Langkah Analisis Kebutuhan

Catatan Kuliah Rekayasa Perangkat Lunak (Software Engineering) Bagian 2

Tujuan 04/07/ :01

Minggu 6 Prinsip & Konsep Desain

ARSITEKTURAL DESIGN. Struktur Arsitektur. Bass, Clements, dan Kazman [Bass, 2003 via Pressman, 2010) mendefinisikan:

REKAYASA PERANGKAT LUNAK LANJUT DESIGN ENGINEERING. Defri Kurniawan M.Kom

DASAR REKAYASA PERANGKAT LUNAK

ANALISA DAN PERANCANGAN SISTEM INFORMASI. Pendekatan Terstruktur dan alat-alat pemodelan Sistem

Pemrograman Web Berbasis Framework. Pertemuan 13 : Pengembangan Project (Bag. 1) Hasanuddin, S.T., M.Cs. Prodi Teknik Informatika UAD

MAKALAH DESAIN PERANGKAT LUNAK. NAMA : RANI JUITA NIM : DOSEN : WACHYU HARI HAJI. S.Kom.MM

PROSES MODEL DESAIN PERANGKAT LUNAK

MODEL DESAIN & DOKUMENTASI DESAIN

Tujuan. entitas yang kemudian akan dibangun. ó Menghasilkan suatu model atau representasi dari. Tim RPL 1 2

PRINSIP DAN KONSEP DESAIN

REKAYASA PERANGKAT LUNAK MATERI TM 12

MAKALAH MODEL DESAIN DAN DOKUMENTASI DESAIN. NAMA : RANI JUITA NIM : DOSEN : WACHYU HARI HAJI. S.Kom.MM

REKAYASA PERANGKAT LUNAK

Catatan Kuliah Rekayasa Perangkat Lunak (Software Engineering) Bagian 2

P10 Konsep & Prinsip Desain. A. Sidiq P.

BAB 1 PENDAHULUAN. satu hal yang sangat dominan dan terjadi dengan sangat pesat. Informasi

BAB II LANDASAN TEORI Membangun Aplikasi Database Oracle dengan VB. Koneksi database adalah sebuah modul (obyek) yang bekerja untuk

BAB V PERANCANGAN MOXIE

Tugas Rekayasa Perangkat Lunak

BAB III METODE PENELITIAN. penelitian. Perancangan tingkat usability. Analisis. Identifikasi Pola Interaksi

BAB II LANDASAN TEORI

REKAYASA PERANGKAT LUNAK. 3 sks Sri Rezeki Candra Nursari reezeki2011.wordpress.com

MODEL DESAIN DOKUMENTASI DESAIN

BAB 3 METODOLOGI PENELITIAN

Nama : Rendi Setiawan Nim :

Design Engineering. Tim RPL. Program Studi Teknik Informatika

Pertemuan 5 Konsep dan Prinsip Desain TIK : Menjelaskan konsep, prinsip dan tahapan dalam perancangan software

A Layered Technology

STUDI DAN IMPLEMENTASI PEMBAYARAN PPOB (PAYMENT POINT ONLINE BANK) STUDI KASUS REKENING PDAM TIRTAWENING KOTA BANDUNG

BAB 2 LANDASAN TEORI

NOTASI DIALOG DAN DESAIN

Ratna Wardani. Department of Electronic Engineering Yogyakarta State University

BAB II LANDASAN TEORI. Data adalah deskripsi tentang benda, kejadian, aktifitas, dan transaksi, yang

Desain arsitektur adalah untuk mengembangkan struktur program modular dan merepresentasikan hubungan kontrol antar modul. Metode desain yang

BAB III METODE PENELITIAN. perancangan sistem, dan tahap evaluasi rancangan sistem. sistematis. Adapun model penelitian dapat dilihat pada Gambar 3.1.

Prinsip dan Konsep Desain Perangkat Lunak

BAB 2 LANDASAN TEORI. menjelaskan beberapa prinsip umum sistem antara lain: menghadapi keadaan-keadaan yang berbeda.

BAB 4 METODOLOGI PEMECAHAN MASALAH

BAB II LANDASAN TEORI

BAB 3 ANALISIS DAN PERANCANGAN PROGRAM

Unified Modelling Language UML

Kegunaan tahap ini adalah untuk memobilisasi dan mengorganisir g SDM yang akan melakukan Reengineering

BAB 1 ASUMSI PERANAN PENGANALISIS SISTEM

ORISINALITAS LAPORAN PENELITIAN...

BAB III LANDASAN TEORI

REKAYASA PERANGKAT LUNAK (RPL) Perancangan PL Pemodelan

SISTEM BASIS DATA 1. WAHYU PRATAMA, S.Kom., MMSI.

PENGENALAN. Perancangan Perangkat Lunak. (Software Engineering) Bertalya Program Pascasarjana Univesitas Gunadarma

ABSTRAK. Kata Kunci: gateway, e-commerce,aplikasi berbasis web,customer relationship management.

BAB III LANDASAN TEORI. organisasi yang pada saat dilaksanakan akan memberikan informasi bagi pengambil

BAB II LANDASAN TEORI. konsep dasar dan definisi-definisi yang berkaitan dengan perangkat lunak yang

REKAYASA PERANGKAT LUNAK MATERI TM 10

ABSTRAK. Kata kunci : voucher elektronik SMS (Short Message Service)

ABSTRAK. v Universitas Kristen Maranatha

Rekayasa Perangkat Lunak

DAFTAR ISI. KATA PENGANTAR... i. DAFTAR ISI... iii. DAFTAR GAMBAR... xi. DAFTAR TABEL... xvii. DAFTAR SIMBOL... xx BAB I PENDAHULUAN...

BAB III TINJAUAN PUSTAKA

Bab 6 PERANCANGAN PERANGKAT LUNAK

REKAYASA PERANGKAT LUNAK. 3 sks Sri Rezeki Candra Nursari reezeki2011.wordpress.com

BAB III METODOLOGI PENELITIAN

BAB IV PERANCANGAN. 4.1 Proses Bisnis Pengadaan Barang

BAB III 3. LANDASAN TEORI. manajemen dan individu lain terhadap kejadian-kejadian internal dan eksternal

Nama : Rendi Setiawan Nim :

LINGKUNGAN BASIS DATA

Dasar-Dasar Pengujian Perangkat Lunak. Fakultas Ilmu Komputer dan Teknologi Informasi Jurusan Sistem Informasi Univesitas Gunadarma

12/9/2010 PERANCANGAN ARSITEKTUR PERANGKAT LUNAK ( 2 ) By TTS

Kuliah#3 TSK-612 Sistem Embedded Terdistribusi - TA 2011/2012. Eko Didik Widianto

BAB II LANDASAN TEORI

Pemahaman mengenai Model arsitektur SisTer Mengetahui Sudut pandang logis Arsitektur Sistem Tersebar. Memahami model Arsitektur sistem

BAB II LANDASAN TEORI

ABSTRACT. vii. Abstract

Abstract. Key Word: SmartHome, SMS, mobile, ignoring feedback, C#, Visual Studio.Net 2005, ActiveXperts SMS and Pager Toolkit 3.2, XML, Atmel AT89S52.

SI402 Arsitektur Enterprise Pertemuan #4 Suryo Widiantoro, ST, MMSI, M.Com(IS)

WebE Analisis & Design. Nisa ul Hafidhoh

Perancangan Database

SISTEM BASIS DATA By Novareza Klifartha

Pengujian Perangkat Lunak Berorientasi Objek. Tim RPL Teknik Informatika

ABSTRAK. Kata Kunci : kamus, Indonesia, Mandarin, kata, kalimat, hanzi, pinyin, bushou.

Testing dan Implementasi Sistem Informasi

BAB III LANDASAN TEORI

NOTASI DIALOG DAN DESAIN

BAB III. Landasan Teori

Transkripsi:

Catatan Kuliah Rekayasa Perangkat Lunak (Software Engineering) Bagian 2 with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 1

Software Engineering: A Practitioner s Approach, 6/e Bab 10 Desain Arsitektur copyright 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited. with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 2

Kenapa Arsitektur? Arsitektur bukanlah PL operasional, namun dia merupakan representasi yang memungkinkan pengembang PL untuk : (1)menganalisa efektivitas desain dalam memenuhi kebutuhan, (2) Mengetahui alternatif2x arsitektur pada keadaan dimana membuat perubahan desain masih relatif lebih mudah, dan (3) Mengurangi resiko terkait dengan konstruksi PL. with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 3

Mengapa Arsitektur Penting? Representasi dari arsitektur PL adalah enabler bagi komunikasi antar pihak (stakeholder) yang tertarik dengan pengembangan sistem berbasis komputer. Arsitketur menyoroti keputusan desain awal yang akan mempunyai pengaruh yang sangat besar pada pekerjaan RPL yang mengikutinya, dan keberhasilan pada entitas sistem operasional. Arsitektur membangun model yang relatif kecil dan mudah digenggam secara intelektual tentang bagaimana sistem distrukturkan dan bagaimana komponen2x bekerja sama [BAS03]. with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 4

Desain Data Pada level arsitektur Desain satu atau lebih database untuk mendukung arsitektur aplikasi Desain method untuk mining isi dari berbagai database Navigasi melalui database2x yang ada dalam usaha untuk mengambil informasi level bisnis yang sesuai Desain sebuah data warehouse sebuah database besar, independen yang mempunyai akses pada data yang disipan dalam database yang melayani sekelompok aplikasi yang dibutuhkan bisnis with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 5

Desain Data Pada level komponen Mengambil objek2x data dan mengembangkan satu set abstraksi data Implementasi atribut2x objek data sebagai satu atau lebih struktur data review struktur data untuk memastikan bahwa relasi yang tepat sudah dibuat Sederhanakan struktur data sesuai dengan kebutuhan with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 6

Desain Data Level Komponen 1. Prinsip2x analisis semantik yang diterapkan pada fungsi dan perilaku harus juga dapat berjalan pada data. 2. Seluruh struktur data dan operasi yang akan dilakukan harus dapat diidentifikasi. 3. Sebuah data dictionary harus dibuat dan digunakan untuk menentukan desain program dan data. 4. Keputusan desain data level rendah harus ditunda hingga akhir proses desain. 5. Representasi struktur dara harus diketahui oleh modul yang menggunakannya langsung dalam struktur tersebut (enkapsulasi). 6. Sebuah pustaka struktur data dan operasi yang memungkinkan untuk diterapkan harus dikembangkan. 7. Desain PL dan bahasa pemrograman harus mendukung spesifikasi dan realisasi dari tipe data abstrak. with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 7

Ragam Gaya Arsitektur Masing2x menggambarkan kategori sistem yang menunjukkan : (1) a sekumpulan komponen (mis database, modul komputasi) yang menunjukkan fungsi yan dibutuhkan sistem, (2) sekumpulan connectors yang memungkinkan komunikasi, koordinasi dan kerjasama antar komponen components, (3) batasan yang menentukan bagaimana komponen dapat diintegrasikan untuk membentuk sistem, dan (4) smodel semantik yang memungkinkan desainer untk memahami properti keseluruhan dari sistem dengan menganlisai properti dalam bagian2x di dalamnya. Data-centered architectures Data flow architectures Call and return architectures Object-oriented architectures Layered architectures with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 8

Data-Centered Architecture with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 9

Data Flow Architecture with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 10

Call and Return Architecture with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 11

Layered Architecture with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 12

Pattern Arsitektural Concurrency aplikasi harus menangani banyak tugas dalam pola yang mensimulasikan paralelisasi operating system process management pattern task scheduler pattern Persistence Data ada jika dia bertahan setelah eksekusi proses yang membuatnya. Ada dua pattern umum :: database management system pattern yang menerapkan penyimpanan dan pengambilan dari DBMS kepada arsitektur aplikasi application level persistence pattern yang membangun fitur persistence pada aristektur aplikasi Distribution pola dimana sistem atau komponen2x di antaranya berkomunkasi dalam lingkungan terdistribusi broker bertindak sebagai orang di tengah antara komponen klient dan komponen server. with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 13

Desain Arsitektur PL harus ditempatkan pada konteks Desain harus menentukan entitas eksternal (sistem lain, piranti, orang) dimana PL berinteraksi dengannya Sekumpulan arsitektur archetypes harus diidentifikasi archetype adalah abstraksi (mirip dengan class) yang menampilkan satu elemen dari perilaku sistem Desainer menentukan struktur sistem dengan memilih komponen PL yang mengimplmentasi masing2x archetype with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 14

Architectural Context Safehome Pro duct Internet-based system control panel homeowner uses target system: Security Function uses surveillance function peers uses sensors sensors with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 15

Archetypes Cont roller communicat es wit h Node Det ect or Indicat or Figure 10.7 UML relationships for SafeHome security function archetypes These courseware materials are to (adapted be used from in conjunction [BOS00]) with Software Engineering: A Practitioner s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 16

Component Structure SafeHome Execut ive Funct ion select ion Ext ernal Communicat ion Management Securit y Surveillance Home management GUI Int ernet Int erface Cont rol panel processing det ect or management alarm processing with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 17

Refined Component Structure SafeHome Executive Ext ernal Communicat ion Management Security GUI Internet Interface Cont rol panel processing det ect or m anagem ent alarm processing Key pad processing scheduler phone communicat ion CP display funct ions alarm sensor sensor sensor sensor sensor sensor with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 18

Analisis Desain Arsitektur 1. Kumpulkan semua skenario. 2. Dapatkan kebutuhan2x, batasan2x, dan gambaran lingkungan. 3. Gambarkan pola/gaya arsitektur yang telah dipilih untuk menangani skenario2x dan kebutuhan2x :: module view process view data flow view 4. Evaluasi kualitas atribut2x dengan melihat setiap atribut dalam isolasi. 5. Kenali kualitas atribut untuk setiap atribut arsitektural untuk masing-masik gaya arsitektur yang spesifik. 6. Lakukkan kritik pada arsitektur2x kandidat (yg dikembangkan pada langkah 3) menggunakan analisis pada langkah 5. with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 19

Metode Desain Arsitektur customer requirements "four bedrooms, three baths, lots of glass..." architectural design with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 20

Memperoleh Arsitektur Program Program Architecture with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 21

Partisi Arsitektur Partisi horizontal dan vertical dibutuhkan with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 22

Partisi Horizontal Tentukan cabang yang terpisah pada hierarki modul untuk setiap fungsi utama Gunakan modul kontrol untuk koodinasi komunikasi antar fungsi2x function 1 function 3 function 2 with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 23

Partisi Vertikal : Factoring Didesain sehingga pengambilan keputusan dan pekerjaan distratifikasi Modul pengambilan keputusan tetap ada di puncak arsitektur decision-makers workers with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 24

Mengapa Arsitektur Terpartisi? Hasilnya adalah PL yang mudah diuji Membawa kepada PL yang lebih mudah dikelola Hasilnya efek samping yang semakin sedikit Hasilnya adalah PL yang lebih mudah dikembangkan with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 25

Desain Terstruktur Tujuan : untuk mendapatkan arsitektur program yang terpartisi pendekatan: DFD dipetakan ke arsitektur program PSPEC dan STD digunakan untuk mengindikasikan setiap modul notasi: diagram struktur with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 26

Karakteristik Aliran Aliran Transformasi Aliran Transaksi with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 27

Pendekatan Pemetaan Umum Isolasi aliran ke dalam dan ke luar batasan; untuk aliran transaksi, isolasi Pusat transaksi Bekerja dari batasan luar, petakan Transformasi DFD ke modul terkait Tambahkan modul kontrol jika dibutuhkan Sempurnakan struktur program Menggunakan konsep modularitas efektif with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 28

Pemetaan Transformasi a b d e f g h c data flow model i j x1 "Transform" mapping x2 x3 x4 b c d e f g i a h j with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 29

Factoring direction of increasing decision making typical "decision making" modules typical "worker" modules with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 30

First Level Factoring main program controller input controller processing controller output controller with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 31

Second Level Mapping D B C A A C control main B mapping from the flow boundary outward D with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 32

Transaction Flow incoming flow T action path with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 33

Transaction Example fixture setting fixture servos operator commands process operator commands report display screen robot control assembly record robot control software in reality, other commands would also be shown with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 34

Refining the Analysis Model 1. 2. 3. 4. 5. write an English language processing narrative for the level 01 flow model apply noun/verb parse to isolate processes, data items, store and entities develop level 02 and 03 flow models create corresponding data dictionary entries refine flow models as appropriate... now, we're ready to begin design! with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 35

noun-verb parse Deriving Level 1 Processing narrative for " process operator commands" Process operator command software reads operator commands from the cell operator. An error message is displayed for invalid commands. The command type is determined for valid commands and appropriate action is taken. When fixture commands are encountered, fixture status is analyzed and a fixture setting is output to the fixture servos. When a report is selected, the assembly record file is read and a report is generated and displayed on the operator display screen. When robot control switches are selected, control values are sent to the robot control system. Process operator command software reads operator commands from the cell operator. An error message is displayed for invalid commands. The command type is determined for valid commands and appropriate action is taken. When fixture commands are encountered, fixture status is analyzed and a fixture setting is output to the fixture servos. When a report is selected, the assembly record file is read and a report is generated and displayed on the operator display screen. When robot control switches are selected, control value s are sent to the robot control system. with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 36

Level 1 Data Flow Diagram operator commands read operator commands Error msg valid command fixture status analyze fixture status fixture setting fixture servos determine command type select report control robot generate report report display screen send control value robot control assembly record robot control system with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 37

Level 2 Data Flow Diagram command error msg read command validate command produce error msg command invalid command determine type status read fixture status combined status determine setting raw setting format setting fixture setting robot control send control value read record record calculate output values values format report report assembly record start /stop with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 38

Transaction Mapping Principles isolate the incoming flow path define each of the action paths by looking for the "spokes of the wheel" assess the flow on each action path define the dispatch and control structure map each action path flow individually with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 39

Transaction Mapping data flow model e a f d b t i g h k l j x1 m n Mapping b t a x2 x3 x4 d e f g h x3.1 l m n i j with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 40 k

Isolate Flow Paths command error msg read command validate command produce error msg command invalid command determine type status read fixture status combined status determine setting raw setting format setting fixture setting robot control send control value read record record calculate output values values format report report assembly record start /stop with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 41

Map the Flow Model process operator commands command input controller determine type read command validate command produce error message fixture status controller report generation controller send control value each of the action paths must be expanded further with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 42

Refining the Structure Chart process operator commands command input controller determine type read command validate command produce error message fixture status controller report generation controller send control value read fixture status determine setting format setting read record calculate output values format report with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 43