Rekayasa Perangkat Lunak TI1153

(1)

Rekayasa

Perangkat Lunak

TI1153

Restyandito

e-mail : dito@ukdw.ac.id website : http://lecturer.ukdw.ac.id/~dito

TI1153 – Software Process © Restyandito - 2

KONSEP DESAIN

Desain

Creative process of transforming the problem into a solution Description of the solution

What ?

Pemecahan masalah tidak unik Sulit mencari pemecahan terbaik Solusi tidak bersifat statis Solusi :

Solusi :

Desain

Customer harus memahami apa yang dilakukan sistem Pengembang harus mengetahui bagaimana sistem bekerja Pihak yang terlibat :

Pihak yang terlibat :

desain konseptual desain teknis Proses Desain : Proses Desain : Æapa Æbagaimana _Desainer customer pengembang desain konseptual desain teknis proses iteratif

(2)

TI1153 – Konsep & Prinsip Desain © Restyandito - 5

Desain

ditulis dalam bahasa yg dipahami customer tidak menggunakan istilah-istilah teknis menjelaskan fungsi sistem

tidak tergantung pada implementasi sistem dihubungkan dengan dokumen requirement Desain Konseptual

Desain Konseptual

menjelaskan konfigurasi perangkat keras, kebutuhan

perangkat lunak, communication interface, I/O, jaringan, dsb.

hirarki dan fungsi dari komponen-komponen perangkat lunak struktur data

alir data Desain Teknis

Desain Teknis

Desain

Kita harus mempertimbangkan dampak dari requirements

non-fungsional

Sistem harus disesuaikan dengan lingkungan implementasi Pemodelan analisis tidak cukup formal, sehingga diperlukan:

peyempurnaan analisis class menentukan determine operations

menentukan bagaimana class saling berkomunikasi

Hasil analisis harus divalidasi

Seberapa baik pemodelan kebutuhan dan analisis menjelaskan sistem? Hal apa yang masih belum jelas?

Mengapa tidak langsung dibuat implementasinya?

TI1153 – Konsep & Prinsip Desain increments © Restyandito - 7 Inception Elaboration Construction Transition

Desain

Phases Core Workflows Requirements Analysis Design Implementation Testing iter. #1 iter. #2 — — — — — iter. #n-1 iter. #n Iteration

Workers & Artifacts

Use-Case Engineer Use-Case Realization —Design bertanggung jawab pada Architect Design

Model ArchitectureDescription

Component Engineer Design Subsystem Interfaces Design Class Deployment Model bertanggung jawab pada bertanggung jawab pada

(3)

Workers

architect- responsible for the integrity and the architecture of

the design and deployment models

use-case engineer- responsible for one or more use-case

realizations—design

makes all textual descriptions and diagrams describing the use-case realization readable and suited for their purpose

component engineer- defines and maintains the operations,

methods, attributes, relationships and implementation of one or more design classes. May also maintain the integrity of one or more subsystems

Artifacts

design model- describes the physical realization of a use case;

focuses on how functional and nonfunctional requirements, together with implementation environment constraints, impact the system

deployment model- describes the physical distribution of the

system in terms of how functionality is distributed among computational nodes

architecture description- contains the architecturally

significant artifacts of the design model and all of the deployment model

Ætwo views of architecture -design model viewand deployment model view

Artifacts

use-case realization—design- describes how a specific use

case is realized and performed in terms of design classes and their objects

design class- an abstraction of a class or similar construct in

the system’s implementation

Æuse programming language to specify a design class

design subsystem- organizes artifacts of the design model

into more manageable pieces

interface- specifies the operations provided by design classes

and subsystems

Æseparates operations from their implementation

Desain - Proses

Use-Case Engineer Architect Component Engineer Architectural Design Design Use Cases Design Classes Design Subsystems

(4)

Analysis

Model

conceptualmodel design Ægeneric lessformal

less expensiveto develop fewlayers

focus on interactions outlineof design created by developer

meetings

may not be maintained

physicalmodel

implementation Æspecific moreformal

more expensiveto develop manylayers

focus on sequence implementationof design created by software

engineering environments

maintained throughout life cycle

Design

Model

Analysis

Model

Design

Model

component level design Interface design architectural design data design pro ces_{s s} pec control spec S.T.D. D.F. D. E.R. D. Data Obj. D esc data dictionary component level design Interface design architectural design data design

Design Model

Component-level designmenghasilkan deskripsi prosedur software.

Interface designmenjelaskan bagaimana software berkomunikasi dalam dirinya, dengan sistem yang bertukar informasi dengannya, dan dengan manusia yang menggunakannya. DFD diperlukan untuk desain ini.

Architectural designmendefinisikan relasi antara elemen-elemen struktural utama, pola desain yang digunakan untuk mencapai kebutuhan yang ditentukan untuk sistem dan batasan-batasan yang mempengaruhi bagaimana desain arsitektural ini diterapkan. Desain ini berdasarkan spesifikasi sistem, model analisis (bagian DFD) dan interaksi antara subsistem.

Data designmengubah informasi menjadi struktur data untuk mengimplementasikan software. Data design dibuat berdasarkan data dictionary dan ERD.

performance criteria maintenance criteria

response time extensibility

throughput modifiability

memory adaptability

portability readability

dependability criteria cost criteria

robustness development

reliability deployment

availability upgrade

fault tolerance maintenance

security administration

safety traceability

end user criteria

utility usability

(5)

Design Issues

data management— Bagaimana penanganan data?

➠ files? relational DBMS? object-oriented DBMS?

access control— Bagaimana penentuan akses?

➠ global access table? access control list? capability?

control flow— Bagaimana proses dimulai dan diatur?

➠ procedure-driven? event-driven? threaded?

boundary conditions

➠ system start-up, system shutdown

➠ exceptions

Sistem dijalankan pada Perangkat Lunak/Perangkat Keras apa?

hardware

System software

distribution

Bahasa pemrograman apa yang dipakai?

OO, non-OO

memory management

Bagaimana sistem yang sudah ada?

DBMS

UIMS

Network facilities

legacy systems

Bagaimana organisasi / orang yang terlibat?

Lokasi yg terdistribusi

Kompetensi tim

Design Issues

Abstraction adalah gambaran dari fungsi suatu program. Gambaran ini bisa bertingkat-tingkat. Tingkat yang paling atas adalah gambaran suatu fungsi program dengan menggunakan bahasa alami. Pada tingkat terendah, menghasilkan abstraksi yang bersifat prosedural / langkah perlangkah dengan menggunakan istilah yang teknis dan bisa diimplementasikan menjadi fungsi program.

Pada saat beralih dari tingkat ke tingkat, kita menggunakan procedural dan data abstraction. Procedural abstraction adalah urutan prosedur yang mempunyai tujuan khusus,dan data abstraction adalah koleksi data yang digunakan pada fungsi tersebut.

1. ABSTRACTION

Konsep Desain

Contoh:

Iklan Part Time Job - Fungsi pendaftaran calon part-timer

1. ABSTRACTION

Konsep Desain

Abstraction 1 (highest level)

Calon part-timer dalam melakukan upload syarat-syarat yang diperlukan untuk melamar: surat lamaran, CV, foto, transkrip, data diri.

Abstraction 2 (lower level)

Procedural abstraction : Data abstraction : tampilkan pilihan part-time job nama is STRING

input data nim is STRING

verifikasi format foto is IMAGE FILE kirim data surat_lamaran is PDF FILE

(6)

Refinement adalah penjelasan detil dari abstraction

Refinement membantu designer untuk memperlihatkan detil dari lowest level dari abstraction. Abstraction dan refinement merupakan konsep yang saling melengkapi.

Contoh dari refinement tentang fungsi sebuah pintu

2. REFINEMENT

Konsep Desain

Software dibagi-bagi menjadi beberapa component yang disebut modul-modul. Modul-modul ini nantinya disatukan / diintegrasikan untuk memenuhi kebutuhan sistem.

Dalam pembentukan modul-modul berlaku pernyataan-pernyataan berikut:

Jika C(p1) > C(p2)dimana Cadalah complexity dari suatu modul, maka E(p1) > E(p2)dimana Eadalah waktu yang diperlukan. Semakin rumit sebuah modul, maka waktu yang digunakan untuk menyelesaikan modul tersebut makin banyak.

C(p1+p2) > C(p1) + C(p2) dan E(p1+p2) > E (p1) + E(p2)

3. MODULARITY

Konsep Desain

Modul yang rumit dipecah lagi menjadi beberapa modul untuk memudahkan penyelesaian masalah. Namun semakin banyak modul, maka waktu/biaya untuk integrasikan modul-modul tersebut juga makin tinggi.

3. MODULARITY

Konsep Desain

TI1153 – Konsep & Prinsip Desain © Restyandito - 24 Modular decomposition (function)

–High-level description of functions

–Lower-level explanations of component organization and interface

Data-oriented decomposition (data)

–High-level description of data structures

–Lower-level description of what data are involved and how they are related

Event-oriented decomposition (events)

–High-level description of states

–Lower-level description of state transformations

Konsep Desain

Menurut Wasserman95

(7)

TI1153 – Konsep & Prinsip Desain © Restyandito - 25 Outside-in design (user inputs)

–High-level description of all possible inputs

–Lower-level description of system response to each input

Object-oriented design (objects)

–High-level description of object types

–Lower-level description of object attributes, actions, and relations

Konsep Desain

3. MODULARITY

struktur software secara keseluruhan : struktur hirarki / berjenjang dari modul-modul program.

Berapa sudut pandang arsitektur perangkat lunak: – conceptual atau logical view (major design elements) – implementation view (modules, packages, etc) – process view (concurrent systems)

– deployment view (distributed systems)

4. SOFTWARE ARCHITECTURE

Konsep Desain

Untuk menggambarkan struktur modul-modul tersebut beberapa model yang ada adalah :

-framework model: identifikasi pola yang berulang-ulang

-dynamic model: identifikasi bagaimana konfigurasi sistem berubah karena kejadian-kejadian tertentu

-process model : fokus pada proses teknis yang harus dikerjakan sistem

-functional model: menggambarkan hirarki sistem berdasarkan fungsinya

4. SOFTWARE ARCHITECTURE

Konsep Desain

Fokus pada detil proses pada tiap modul. Prosedur menjelaskan proses, urutan kejadian, proses perulangan, penentuan keputusan / arah. Ini bisa digambarkan dengan menggunakan Flow Chart yang bertingkat.

5. SOFTWARE PROCEDURE

Konsep Desain

Ide dari information hiding (menyembunyikan informasi) adalah modul dirancang sedemikian rupa sehinga inforamsi (prosedur dan data) yang di dalamnya tidak dapat di akses oleh modul lain yang tidak memerlukannya.

Modul yang efektif adalah modul yang berdiri sendiri dan berkomunikasi dengan modul lain yang memang diperlukan.

(8)

Sistem merupakan serangkaian komputasi independen (filter) yang secara bertahap merubah (transform) masukan.

PIPES AND FILTERS MODEL

Desain Arsitektur

TI1153 – Konsep & Prinsip Desain © Restyandito - 30 Keuntungan

;Filter dapat digunakan kembali

;sistem dapat diextends

;concurrency Kerugian

:batch processing

:bagaimana menangani aplikasi yg interaktif?

:filter dapat menduplikasi fungsionalitas

:bagaimana menangani error?

PIPES AND FILTERS MODEL

Desain Arsitektur

Pada model ini data disimpan secara terpusat untuk semua sub-sistem.

REPOSITORY MODEL

Desain Arsitektur

;Efisien untuk share jumlah data yang besar

;Sub-system tidak perlu repot dengan bagaimana data dibuat dan manajemen terpusat contoh: backup, keamanan, re-index. Kerugian

:Sub-system harus mengikuti model yang sudah ditetapkan.

:Evolusi data sulit dan mahal

:Sulit untuk distribusi layanan secara efisien, karena yang melayani hanya satu.

REPOSITORY MODEL

(9)

Model ini terdiri dari sekumpulan server yang berdiri sendiri dan masing-masing menyediakan layanan untuk sub-sistem. Ada client-client (sub-system) yang menggunakan layanan server dan tersedia network yang mengijinkan client untuk akses layanan dari server.

CLIENT-SERVER MODEL

Desain Arsitektur

;Distribution data secara langsung

;Penggunaan sistem jaringan secara efektif –hardware jadi murah

;Mudah untuk tambahkan server baru atau updgrade server yang sudah ada

Kerugian

:Tidak ada data model, jadi organisasi data macam-macam, sehingga integrasi data sulit

:Redundant management

:Tidak ada pusat register nama dan service, sehingga kalau tidak tahu nama server dan service-nya sulit ditemukan

CLIENT-SERVER MODEL

Desain Arsitektur

Model ini membangun sistem dengan lapisan-lapisan hirarkis dan protokol-protokol interaksi.

-Lapisan dalam, menyediakan servis untuk lapisan luar -Lapisan luar, berlaku sebagai ‘klien’ dari lapisan dalam

LAYERING MODEL

Desain Arsitektur

LAYERING MODEL

(10)

;Abstraksi hirarkis

;Relatif mudah untuk menambah lapisan

;Lapisan dapat digunakan kembali Kerugian

:Sulit untuk membuat struktur sistem pada lapisan

:Abstraksi hirarkis tidak selalu tampak dari requirement

:performance

LAYERING MODEL

Desain Arsitektur

PRINSIP DESAIN

Desain yang baik, secara umum jika dapat meningkatkan keuntungan dengan mengurangi biaya dan meningkatkan pendapatan.

Prinsip Desain

Beberapa prinsip desain yang baik diantaranya: — Usability

— Efficiency — Reliability — Maintainability — Reusability

Prinsip Desain

#

1 Divide and conquer

Memecahkan masalah yg besar lebih sulit dibandingkan dengan menyelesaikan serangkaian masalah yang kecil-kecil

)

sekelompok orang bekerja utk masalah tertentu

)

tidak semua orang memiliki keahlian / spesialisasi

)

bagian-bagian yg kecil lebih mudah dipahami

)

bagian bisa diubah tanpa mempengaruhi bagian lain Apa yang dibagi?

?

sistem terdistribusi Ö client server

?

sistem Ö sub-sistem

?

sub-sistem Ö beberapa package

(11)

Prinsip Desain

#

2 High Cohesion

Sub-sistem / modul yg berhubungan erat dipisahkan dari sub-sistem / modul yg tidak berhubungan.

Jenis-jenis kohesi:

functional ➠satu modul satu fungsi (single computation) layer ➠fasilitas utk mengakses fungsi2 yg berhubungan

communicational➠modul yg mengakses/memanipulasi data yg sama sequential➠procedure yg menjadi input utk procedure berikutnya Procedural ➠procedur yg saling menggunakan satu dg lain temporal➠modul yg dijalankan pada saat yg bersamaan utility➠utility yg berhubungan dan tidak dapat dikelompokkan

di salah satu kohesi di atas

Prinsip Desain

#

3 Low Copling

Copling terjadi jika terjadi saling ketergantungan antar modul

X

Prinsip Desain

#

3 Low Copling

Jenis-jenis kopling:

content ➠satu komponen dpt memodifikasi data dr komponen lain common ➠penggunaan variabel global

control➠satu komponen memanggil procedur di komponen lain stamp➠satu komponen menggunakan obj lain sbg argumen data ➠tipe argumen yhg digunakan berupa primitive/class library routine➠suatu rutin (method) memanggil rutin yg lain

inclusion/import➠komponen mengimport/include package external➠komponen memiliki ketergantungan dg faktor eksternal

seperti OS, shared library, perangkat keras

Prinsip Desain

#

4 High Level Abstraction

Desain yang menyembunyikan detail sehingga mengurangi kompleksitas

Prinsip Desain

#

5 Increase Reusability

Prinsip Desain

#

6 Design for Flexibility

Mengantisipasi perubahan yg mungkin terjadi di masa depan

)

mengurangi kopling dan meningkatkan kohesi

)

membuat abstraksi

(12)

Prinsip Desain

#

7 Anticipate Obsolesence

Merencanakan untuk mengikuti perkembangan teknologi

)

hindari penggunaan teknologi yg masih dini

)

hindari penggunaan library yg spesifik pada environment tertentu

)

cari SW yg memiliki dokumentasi / library yg baik

)

pilih vendor yang memiliki dukungan jangka panjang

)

gunakan teknologi dan standar yang didukung oleh banyak vendor

Prinsip Desain

#

8 Design for Portability

Prinsip Desain

#

9 Design for Testability

Referensi

Pressman, Roger S., Software Engineering: A Practitioner’s Approach, 6th_Edition_{, McGraw-Hill,}

2005 (bab 9)

Pressman,Roger S., Rekayasa Perangkat Lunak: Pendekatan Praktisi (Buku 1), Penerbit Andi, 2002 (bab 13)