Kejuruteraan Perisian
description
Transcript of Kejuruteraan Perisian
Kejuruteraan Perisian
REKABENTUK SISTEM
Definisi serta dokumen rekabentuk Senibina rekabentuk Proses senibina rekabentuk
System structuring/decompositionControl modellingModular decomposition
Sifat rekabentuk yang baik
REKABENTUK Definisi: Suatu proses kreatif yang
menukarkan masalah kepada penyelesaian.
Menggunakan maklumat daripada spesifikasi keperluan untuk menerangkan masalah.
Penyelesaian akan diberi sekiranya ia memenuhi keseluruhan spesifikasi keperluan.
Rekabentuk Konseptual & Teknikal
Perekabentuk mesti penuhi kehendak pelanggan dan juga pembangun sistem
Pelanggan: faham apa yang akan sistem lakukan
Pembangun: mesti faham bagaimana sistem akan berfungsi.
Rekabentuk konseptual
Memberitahu pelanggan apa yang akan sistem dapat lakukan.
Memberi tumpuan kepada fungsian sistem.
Pelanggan akan mengesahkan rekabentuk logikal sistem sebelum perekabentuk tukar kepada rekabentuk teknikal.
Rekabentuk teknikal
Translasi rekabentuk konseptual kepada dokumen yang lebih mendalam.
Pembangun akan faham apa perisian serta perkakasan sebenar yang diperlukan untuk menyelesaikan masalah pelanggan
Ia menerangkan bentuk (form) akhir yang akan diambil oleh sistem.
RekabentukKonseptual
fungsi
RekabentukKonseptual
fungsi
RekabentukTeknikal
bentuk
RekabentukTeknikal
bentukPerekabentu
k sistem
Pelanggan Pembangun sistem
BAGAIMANAAPA
Senibina Rekabentuk Menyatakan struktur keseluruhan
bagi sistem perisian. Peringkat awal bagi proses
rekabentuk sistem. Mewakilkan hubungan antara
spesifikasi dan proses rekabentuk. Mengenalpasti komponen sistem
utama dan komunikasi sesamanya.
Proses Senibina Rekabentuk System structuring/decomposition
Sistem dihuraikan (decomposed) kepada beberapa subsistem utama dan komunikasi antara subsistem dikenalpasti.
Control modelling Model kawalan hubungan antara subsistem
yang berlainan akan dikenalpasti. Modular decomposition
Subsistem yang dikenalpasti akan dihuraikan kepada modul-modul.
Subsistem & Modul Subsistem merupakan sistem yg
tersendiri dimana operasinya tidak bergantung kepada perkhidmatan yg disediakan oleh subsistem lain.
Modul merupakan komponen sistem yg menyediakan perkhidmatan kepada komponen lain tetapi ia tidak dianggap sebagai sistem yg berasingan.
Model-model Senibina Model senibina yg berlainan mungkin
akan dihasilkan semasa proses rekabentuk. Antaranya: Model struktur statik menunjukkan
komponen sistem utama. Model proses dinamik menunjukkan struktur
proses sistem. Model antaramuka menyatakan antaramuka
subistem. Model hubungan seperti model aliran data
(DFD).
Proses Senibina Rekabentuk (1) System Structuring
Berkaitan dengan penghuraian sistem kepada interaksi subsistem.
Biasanya diwakilkan sebagai rajah blok yg memaparkan pandangan struktur sistem.
Model yg spesifik menunjukkan bgmn subsistem berkongsi data, diagihkan dan antaramuka antara subsistem.
Packing robot control system
Visionsystem
Objectidentification
system
Armcontroller
Grippercontroller
Packagingselectionsystem
Packingsystem
Conveyorcontroller
Mewakili subsistem
Mewakili data/ kawalan
System structuring: Repository model Subsistem mesti menukar (exchange)
data. Ianya boleh dilakukan dengan 2 cara: Data yg dikongsi diletakkan pada pangkalan
data pusat (repository) dan boleh dicapai oleh semua subsistem lain.
Setiap subsistem mempunyai pangkalan data yg tersendiri dan boleh menghantar data kepada subsistem lain.
Model yg biasa digunakan apabila koleksi data yg besar ingin dikongsi bersama.
Contoh repository model: CASE toolset architecture
Projectrepository
Designtranslator
Programeditor
Designeditor
Codegenerator
Designanalyser
Reportgenerator
Repository model Kelebihan:
Cara efisien untuk kongsi jumlah data yg besar.
Subsistem tidak perlu hirau bagaimana data diurus. Pengurusan berpusat (back-up, keselamatan dll).
Model kongsian diterbitkan menggunakan skema repository.
Kelemahan: Subsistem mesti bersetuju dengan model data
repository. Evolusi data adalah sukar dan agak mahal. Sukar untuk mengagihkan data kepada
beberapa mesin (masalah ketidakkonsistenan).
System structuring:Client-server model Model sistem teragih (distributed) yg
menunjukkan bagaimana data dan pemprosesan diagihkan merentasi pelbagai komponen.
Terdapat set pelayan (stand-alone server) yg menyediakan perkhidmatan spesifik spt cetakan, pengurusan data dll.
Terdapat set klien (client ) yg memanggil perkhidmatan tersebut.
Terdapat rangkaian yg membenarkan klien mencapai pelayan.
Client-server model Senibina client-server yg paling mudah
dipanggil two-tier client server di mana aplikasi diorganisasi kepada server dan set client. Ia boleh terdiri daripada 2 bentuk: Thin-client model: Semua pemprosesan
aplikasi dan pengurusan data dilaksanakan pada server. Client cuma bertanggjawab untuk menjalankan (run) persembahan perisian.
Fat-client model: Server hanya bertanggungjawab bagi pengurusan data. Perisian pada client melaksanakan logik aplikasi dan interaksi dengan pengguna sistem.
Client-server model:Two-tier client server
Server
Data ManagementApplication Processing
ClientPresentation
Thin-client model
Server
Data ManagementClientPresentation
Fat-client model
ApplicationProcessing
Contoh: Banking ATM systems
Contoh Client-server: Film and picture library
Catalogueserver
Catalogue
Videoserver
Film clipfiles
Pictureserver
Digitizedphotographs
Hypertextserver
Hypertextweb
Client 1 Client 2 Client 3 Client 4
Wide-bandwidth network
Senibina client-server Kelebihan:
Pengagihan data dan pemprosesan dilaksanakan kepada beberapa pemproses (klien dan pelayan).
Menggunakan sistem rangkaian secara efektif (boleh kurangkan kos perkakasan)
Mudah untuk menambah/upgrade pelayan baru (tanpa perlu mengganggu sistem lain)
Kelemahan: Tiada perkongsian model data, jadi subsistem
guna organisasi data yg berbeza (tidak efisien) Masalah prestasi sekiranya pertukaran data
antara klien-pelayan adalah besar (bandwith rangkaian yg rendah)
System structuring: Abstract machine model Digunakan untuk memodelkan
antaramuka antara subsistem. Mengorganisasi sistem kepada set layer
(abstract machine) yg mana setiap satu menyediakan set perkhidmatan.
Menyokong pembangunan secara penokokan (incremental) kepada subsistem dalam layer yg berlainan. Apabila antaramuka layer berubah, hanya layer yg bersebelahan sahaja yg terjejas.
Bagaimanapun, agak sukar untuk menstruktur sistem dengan cara ini.
Contoh Abstract machine model: Version management system
Operatingsystem
Database system
Object management
Version management
Proses Senibina Rekabentuk (2) Control models
Berkaitan dengan aliran kawalan antara subsistem (berbeza dengan system structuring/ decomposition model)
Terdapat 2 pendekatan umum kepada kawalan:
1. Centralised control – satu subsistem mempunyai tanggungjawab keseluruhan bagi kawalan (memula/menghenti) subsistem lain.
2. Event-based control – setiap subsistem boleh respon kepada event luaran dari subsistem lain atau persekitaran sistem.
Contoh Centralised control:
Routine 1.2Routine 1.1 Routine 3.2Routine 3.1
Routine 2 Routine 3Routine 1
Mainprogram
Call-return model• Top-down subroutine model where control starts at the top of a subroutine hierarchy and moves downwards. Applicable to sequential systems.
Contoh Event-based control:
Sub-system1
Event and message handler
Sub-system2
Sub-system3
Sub-system4
Broadcast models• An event is broadcast to all sub-systems. Any sub-system which can handle the event may do so.• Effective in integrating sub-systems on different computers in a network.
Proses Senibina Rekabentuk (3) Modular Decomposition
Melibatkan proses menghuraikan subsistem kepada modul-modul yg lebih kecil.
Terdapat 2 pendekatan: 1. Model berorientasikan objek – sistem
dihuraikan kepada interaksi objek-objek. 2. Model aliran data – sistem dihuraikan
kepada modul fungsian yg menukarkan input kepada output (pipeline model)
Modular Decomposition:Model berorientasikan objek Menstruktur sistem kepada set objek yg
mempunyai pergantungan yg lemah (loosely coupled) dan antaramuka yg ditakrif dengan baik.
Decomposition berorientasikan objek berkaitan dengan mengenalpasti kelas objek, atribut serta operasi (metod).
Dalam perlaksanaan, objek (instance) akan dicipta dari kelas dan sebahagian model kawalan digunakan untuk kordinasi operasi objek.
Contoh Model berorientasikan objek: Invoice processing system
issue ()sendReminder ()acceptPayment ()sendReceipt ()
invoice#dateamountcustomer
Invoice
invoice#dateamountcustomer#
Receipt
invoice#dateamountcustomer#
Payment
customer#nameaddresscredit period
CustomerKelas Objek
Atribut
Operasi
Modular Decomposition:Model Aliran Data Juga dikenali sebagai pipe and filter
model (dimana transformasi fungsian memproses input kepada output)
Pendekatan ini mempunyai variasi yang biasa dimana jika transformasi adalah berjujukan, ia digelar model jujukan berkumpulan (batch), yg banyak digunakan untuk data processing systems.
Model ini tidak sesuai untuk sistem interaktif (sukar untuk model event-based data input daripada pengguna)
Contoh Model aliran data: Invoice processing system
Read issuedinvoices
Identifypayments
Issuereceipts
Findpayments
due
Receipts
Issuepaymentreminder
Reminders
Invoices Payments
Fungsian transformasi
Sifat rekabentuk yang baik Rekabentuk berkualiti tinggi akan
beri kesan kepada kualiti produk: Ease of understanding Ease of implementation Ease of testing Ease of modification Correct translation from requirements
specification
Sifat rekabentuk yang baik: Component Independence Abstraction & information hiding
membenarkan kita untuk memeriksa komponen mana yang berkaitan antara satu sama lain dalam rekabentuk keseluruhan.
Untuk kenalpasti dan mengukur darjah kebergantungan komponen di dalam rekabentuk, guna 2 konsep: Coupling Cohesion
Component Independence:1. Coupling Merujuk kepada darjah kebergantungan
yg wujud antara komponen untuk berfungsi secara sempurna. Highly coupled: pergantungan
(dependence) yang kuat di antara komponen-komponen tersebut.
Loosely coupled: ada pergantungan, tetapi perhubungan di antara komponen adalah lemah
Uncoupled: tiada perhubungan lansung, pergantungan bebas.
Component CouplingUncoupled
Loosely coupled
Highly coupled
Contoh pergantungan:• rujukan antara komponen• penghantaran data antara komponen• jumlah kawalan antara komponen• kekompleksan antaramuka antara komponen
Component Independence:2. Cohesion Merujuk kepada ‘internal glue’ dimana
sesuatu komponen itu dibangunkan. Sesuatu komponen itu dikatakan
cohesive jika kesemua arahan di dalam komponen bertujuan untuk menyempurnakan satu tugas atau set tugas yg berkaitan (fungsian berkait)
Lebih ‘cohesive’ sesuatu komponen, lebih berkait antara bahagian-bahagian dalaman komponen (mudah difahami, koding, debug dan selenggara)
Component Cohesion
Fungsi A
Fungsi BFungsi C
Fungsi DFungsi E
CoincidentalFungsi tidak
berkait
Fungsi A
Fungsi B
Fungsi C
ProceduralFungsi berkait
mengikut susunan
Contoh cohesion:
Fungsi A – part 1
FunctionalFungsi berkait
berjujukan lengkap
Fungsi A – part 2
Fungsi A – part 3
Lebih cohesive
Sifat rekabentuk yang baik: Exception Identification & Handling Exception:
Kegagalan untuk menyediakan perkhidmatan (system down)
Menyediakan perkhidmatan atau data yang salah
Corrupting data Setiap exception yang dikenalpasti
boleh ditangani dengan 3 cara: Retrying (restore system to previous state) Correct (restore system, correct some
aspect and try again) Report (restore system, report problem and
stop service)
Sifat rekabentuk yang baik: Fault Prevention & Tolerance Rekabentuk mesti menyertakan ‘fault’
dan cuba mengurangkan gangguan serta memaksimakan keselamatan.
Fault: apabila manusia melakukan kesilapan, keputusannya akan menghasilkan ‘fault’ dalam produk perisian.
Failure: departure of the system from its required behaviour. Boleh dikesan sebelum dan selepas penghantaran sistem.
Rekabentuk Sistem: Rumusan
Senibina rekabentuk (perisian) merupakan rangkakerja asas bagi menstruktur sistem. Model senibina yg berbeza spt structural, control dan decomposition model mungkin akan dibangunkan semasa senibina rekabentuk.
Sistem yg besar (kompleks) tidak selalunya berdasarkan kepada model senibina tunggal. Sistem ini biasanya menyertakan pelbagai model pada aras (abstraction) yg berlainan.
Antara sifat yang perlu ada pada sistem: modularity, cohesion, coupling, fault tolerance, user-interface etc.