rekayasa perangkat lunakdinus.ac.id/repository/docs/ajar/10_11._design_-_rekayasa_perangkat... ·...
TRANSCRIPT
Teknik Informatika S1
Disusun Oleh: Egia Rosi Subhiyakto, M.Kom, M.CS Teknik Informatika UDINUS [email protected] +6281329571612
Design
Rekayasa Perangkat Lunak
SILABUS MATA KULIAH
8. Pembahasan UTS + Tugas SKPL
9. Presentasi SKPL
10. Design + Tugas DPPL
11. Presentasi DPPL
12. Testing
13. Presentasi Tugas Besar (1)
14. Presentasi Tugas Besar (2)
Design Engineering
1. Transformasi dari Model Analisis ke Model
Perancangan
2. Design Process and Design Quality
3. Design Concepts (Abstract, Architecture, Modularity,
Information Hiding, Functional Hiding, Functional
Independence, Refinement)
4. Design Model
Design Process Sebuah proses iteratif melalui kebutuhan yang diterjemahkan ke
dalam sebuah „cetak biru‟ untuk membangun perangkat lunak.
Seluruh proses perancangan, kualitas peningkatan perancangan
dinilai dengan sekumpulan kajian teknikal formal atau
perancangan walkthroughs.
Petunjuk untuk mengevaluasi sebuah perancangan yang baik :
• Rancangan harus diimplementasikan seluruhnya baik kebutuhan yang explicit
dan implicit
• Rancangan harus mudah dibaca
• Rancangan seharusnya menyediakan sebuah gambaran lengkap dari
perangkat lunak
Design Process
Cetak biru (blue print) adalah kerangka kerja terperinci
(arsitektur) sebagai landasan dalam pembuatan kebijakan
yang meliputi penetapan tujuan dan sasaran, penyusunan
strategi, pelaksanaan program dan fokus kegiatan serta
langkah-langkah atau implementasi yang harus dilaksanakan
oleh setiap unit di lingkungan kerja.
Evolution of S/W Design
Development of modular program
Structural programming
Aspek prosedural dari definisi perancangan
Terjemahan dari aliran data atau struktur data ke dalam
definisi perancangan.
OO design
Design Principles
Proses perancangan seharusnya tidak “tunnel vision”
-> Seharusnya mempertimbangkan pendekatan alternatif.
Perancangan seharusnya dilacak dari model analisis
Perancangan seharusnya menggunakan pola rancangan
Perancangan seharusnya meminimalkan jarak intelektual
antara software dan masalah yang ada di dunia nyata.
Design Principles (Cont.)
Perancangan seharusnya memperlihatkan keseragaman dan
keterpaduan.
Perancang seharusnya disusun untuk mengakomodasi
perubahan.
Perancangan harus disusun untuk menghaluskan, ketika
data, kejadian, atau operasi menyimpang ditemukan.
Design Principles (Cont.)
Perancangan bukan coding, dan coding bukan perancangan.
Perancangan harus dinilai untuk kualitas ketika sedang
dibuat, bukan setelah jadi.
Perancangan harus direview untuk meminimalkan
kesalahan konseptual.
Fundamental Concepts
Abstraction – mengikuti perancangan untuk fokus pada
pemecehan masalah tanpa dihubungkan dengan
penyimpangan detil di level terendah
Refinement – Proses elaborasi dimana perancang
menyediakan kesuksesan lebih detil untuk setiap
kompenen perancangan.
Fundamental Concepts (Cont.)
Modularity – persetujuan dimana software dapat
dimengerti oleh pengujian komponenenya secara
independent oleh yang lainnya.
Software architecture – Keseluruhan struktur dari
komponen s/w dan cara dimana struktur menyediakan
konseptual integritas untuk sebuah sistem.
Fundamental Concepts (Cont.)
Control hierarchy or program structure - merupakan
organisasi modul dan menyiratkan hirarki kontrol, tetapi
tidak mewakili aspek prosedural dari perangkat lunak
(misalnya: urutan peristiwa)
Structural partitioning - partisi horisontal
mendefinisikan tiga partisi (input, transformasi data, dan
output); partisi vertikal (factoring) mendistribusikan
kontrol secara top-down (keputusan kontrol dalam modul
tingkat atas dan bekerja pengolahan dalam modul tingkat
yang lebih rendah)
Fundamental Concepts (Cont.)
Data structure - representasi dari hubungan logis antara
elemen data individu (memerlukan desain algoritma).
Software procedure – spsesifikasi yang tepat untuk
pengelolaan (event sequences, decision points, repetitive
operations, data organization/structure).
Information hiding - informasi (data dan prosedur) yang
terkandung dalam sebuah modul dapat diakses untuk
modul yang tidak perlu untuk informasi tersebut.
Data Abstraction
door
implemented as a data structure
manufacturer model number type swing direction inserts lights type number weight opening mechanism
Data Design
Menyaring objek data dan membangun sekumpulan
abstraksi data.
Mengimplementasikan atribut objek data sebagai satu
atau lebih struktur data.
Mereview struktur data untuk menjamin bahwa hubungan
yang tetap telah ditetapkan.
Dibutuhkan struktur data yang sederhana.
Procedural Abstraction
open
implemented with a "knowledge" of the object that is associated with enter
details of enter algorithm
Stepwise Refinement
open
walk to door; reach for knob; open door; walk through; close door.
repeat until door opens turn knob clockwise; if knob doesn't turn, then take key out; find correct key; insert in lock; endif pull/push door move out of way; end repeat
Functional Independence
COHESION - the degree to which a module performs one and only one function. COUPLING - the degree to which a module is "connected" to other modules in the system.
Functional Independence
Kohesi
Modul yang kohesif seharusnya hanya melakukan satu hal
saja
(kohesi tinggi = fungsional <> koinsidental).
Kopling
Sehubungan dengan perangkaian dengan modul lain, maka
modul yang baik seharusnya memiliki hubungan yang
sederhana (kopling rendah).
Functional Independence
Kohesi
Derajat/ level dimana sebuah modul membentuk satu dan
hanya satu fungsi
Kopling
Derajat dimana sebuah modul dihubungkan pada modul lain
dalam sebuah sistem.
Cohesion and Coupling Spectrum
*Coincidental
*Utility
*Temporal
*Procedural
*Sequential
*Communicational
*Layer
*Functional
*No direct coupling
*External coupling
*Inclusion or import coupling
*Type use coupling
*Routine call coupling
*Data coupling
*Stamp coupling
*Control coupling
*Common coupling
*Content coupling
low low
high high
Why Information Hiding?
• mengurangi kemungkinan "efek samping"
• membatasi pengaruh global dari keputusan desain lokal
• menekankan komunikasi melalui interface yang
dikendalikan
• melarang penggunaan data global
• mengarah ke enkapsulasi-atribut dari desain kualitas
tinggi
• Hasil dalam kualitas perangkat lunak yang lebih tinggi
Why Architecture?
• Arsitektur bukanlah operasi perangkat lunak. Sebaliknya,
itu adalah representasi yang memungkinkan seorang
insinyur perangkat lunak untuk:
(1) menganalisis efektivitas desain dalam memenuhi persyaratan
yang dinyatakannya,
(2) mempertimbangkan alternatif arsitektur pada tahap ketika
membuat perubahan desain masih relatif mudah, dan
(3) mengurangi risiko yang terkait dengan pembangunan perangkat
lunak.
Architectural Styles
• Data-centered architectures
• Data flow architectures
• Call and return architectures
• Object-oriented architectures
• Layered architectures
Horizontal Partitioning
Mendefinisikan cabang terpisah dari hirarki modul untuk
setiap fungsi utama
Gunakan modul kontrol untuk mengkoordinasikan komunikasi
antara fungsi
function 1 function 3
function 2
Vertical Partitioning: Factoring
Pengambilan keputusan dan kerja yang bertingkat
Pengambilan keputusan modul harus berada di atas
arsitektur
workers
decision-makers
Why Partitioned Architecture?
Menghasilkan software yang lebih mudah diuji
Menunjuk pada software yang lebih mudah dipelihara.
Menghasilkan propagasi dari sedikit efek samping
Menghasilkan software yang lebih mudah diperluas.
Interface Design
1. Interface Design
2. User Interface Design (Three Golden Rules)
3. User Interface Analysis and Design
4. Data Design
5. Component Level Design
Interface Design
Elemen-elemen perancangan interface untuk perangkat
lunak menjelaskan Bagaimana arus informasi masuk dan
keluar dari sistem, dan bagaimana arus informasi tersebut
berkomunikasi diantara komponen2 yang didefinisikan
sebagai bagian dari arsitektur.
Interface Design
Fokus Interfaces Design 3 Area
1. Inter-modular interface design
2. External interface design
3. Human-Computer Interface (HCI) design
Desain Interface
1. Internal : merupakan desain interface antarmodul dalam
PL yang dikendalikan oleh data yang harus mengalir di antara
modul-modul. Aliran transformasi dalam DFD merupakan
pijakan utama dalam desain ini selain kemampuan bahasa
pemrograman.
Desain Interface
2. Eksternal: merupakan interface untuk entitas eksternal
(tidak termasuk manusia), misalnya sensor pada PL Safehome.
3. Manusia – Mesin: merupakan interface antara manusia
dengan PL (Human – Computer Interface). Interface ini
memiliki tantangan besar karena berkaitan dengan pengguna
dengan berbagai karakter yang lebih sulit untuk dipelajari.
Terdapat tiga kategori pedoman desain HCI sbb.
Desain Human Computer Interface (HCI)
1. Interaksi Umum
Format konsisten
Perlindungan thd kegagalan
Berikan petunjuk singkat (tools tips) pada setiap button / ikon / nama
Berikan umpan balik
Konfirmasi untuk aksi destruktif (misal Hapus)
Ijinkan pembatalan (misal Undo)
Kurangi jumlah informasi yang harus diingat
Efisiensi dalam dialog, gerakan (tangan), pemikiran
Kategorikan aktivitas sejenis dan posisinya di layar
Sediakan Help yang sensitif konteks
Gunakan perintah dan nama2 yang pendek
Desain Human Computer Interface (HCI)
2. Input
Minimalkan jumlah aksi input (combo box, list, dsb.)
Konsisten
Berikan kemungkinan kustomisasi input (utk advance user)
Mode input harus fleksibel (mouse / keyboard)
Non-aktifkan button/ ikon yang tidak relevan dengan aksi
Berikan kesempatan untuk mengontrol aliran interaksi (mengubah,
membetulkan, mengulang)
Sediakan Help
Jangan meminta aktivitas manual (perhitungan, tanggal, waktu, dsb)
bila dapat dilakukan oleh PL
Desain Human Computer Interface (HCI)
3. Output Tampilkan informasi yang relevan dg konteks
Jangan membanjiri pemakai dg informasi
Gunakan label, singkatan, warna yg standar dan konsisten
Peliharalah konteks visual saat pengguna melakukan zoom-in / zoom-out
Pesan kesalahan harus memiliki arti yang jelas
Gunakan variasi huruf, indentasi, pengelompokan untuk memudahkan pemahaman
Gunakan jendela untuk tipe-tipe informasi yang berbeda
Gunakan tampilan alami (bukan angka / grafik) bila memungkinkan
Geografi layar dioptimalkan shg tidak ada jendela yang „hilang‟ / sulit ditemukan
Berikan kemungkinan kustomisasi output (utk advance user)
Jangan ada informasi / data yang tidak lengkap / hilang sebagian
User Interface Design
Three golden rules – Theo Mandel
1. Place user in control
“What I really would like is a system that reads my mind. It
knows what I want to do before I need to do it and makes it very
easy for me to get it done. That‟s all, just that.”
2. Reduce the user’s memory load
The more a user has to remember, the more error-prone
interaction with the system will be
The system should „remember‟
3. Make the interface consistent
User Interface Design
Tiga aturan emas Theo Mandel
1. Menempatkan user di dalam kontrol
“ Apa yang saya inginkan adalah sebuah sistem yang membaca pikiran
saya. Dia tahu apa yang ingin saya lakukan sebelum saya butuhkan dan
membuat mudah saya untuk melakukannya”
2. Mengurangi muatan memori user,
Semakin banyak user harus mengingat, semakin banyak interaksi
kesalahan dengan sistem
Sistem seharusnya mengingat
3. Membuat Interface yang Konsisten
Place User in Control
• Define interaction in such a way that the user is not
forced into performing unnecessary or undesired actions
• Provide for flexible interaction (users have varying
preferences)
• Allow user interaction to be interruptible and reversible
• Streamline interaction as skill level increases and allow
customization of interaction
• Hide technical internals from the casual user
• Design for direct interaction with objects that appear on
the screen
Reduce User Memory Load
• Reduce demands on user's short-term memory (exp.
providing visual cues)
• Establish meaningful defaults (“reset” option should be
available)
• Define intuitive short-cuts (easy to remember)
• Visual layout of user interface should be based on a
familiar real world metaphor
• Disclose information in a progressive fashion
Make Interface Consistent
• Allow user to put the current task into a meaningful
context
• Maintain consistency across a family of applications
• If past interaction models have created user
expectations, do not make changes unless there is a good
reason to do so
User Interface Analysis and Design
• The models
o The human engineer establishes a user model
o The software engineer creates a design model
o The end-user develops a mental image or user‟s mental model
(system perception)
o The implementers create an implementation model
• The process
o User, task, and environment analysis and modeling
o Interface design
o Interface construction
o Interface validation
The Models • User model
o end user profiles:
• Novice
• Knowledgeable, intermittent user,
• Knowledgeable, frequent users
• Design model
o incorporates data, architectural, interface, and procedural
representations of the software
• User's model or system perception
o user's mental image of system
• Implementation model
o look and feel of the interface and supporting media
The Process - User Analysis
• Understand who the end-users are
• What is likely to motivate and please them
• How they can be grouped into different user classes or
profiles
• What their mental models of the system are
• How the user interface must be characterized to meet
their needs
The Process - Task Analysis and Modeling
• Software engineer studies tasks human users must complete to accomplish their goal in the real world without the computer and map these into a similar set of tasks that are to be implemented in the context of the user interface
• Software engineer studies existing specification for computer-based solution and derives a set of tasks that will accommodate the user model, design model, and system perception
• Software engineer may devise an object-oriented approach by observing the objects and actions the user makes use of in the real world and model the interface objects after their real world counterparts
Know the user, know the tasks
The Process - Analysis of Display Content
• Type of content
o Character-based reports
o Graphical displays
o Specialized information
• Source of content
o Generated by components
o Acquired from data store
o Transmitted from systems external
The Process - Interface Design Activities
• Establish the goals and intentions of each task
• Map each goal/intention to a sequence of specific actions
• Specify the action sequence of tasks and subtasks (user scenario)
• Indicate the state of the system at the time the user scenario is
performed
• Define control mechanisms object and action
• Show how control mechanisms affect the state of the system
• Indicate how the user interprets the state of the system from
information provided through the interface
Interface Design Issues
• System response time
o time between the point at which user initiates some control
action and the time when the system responds
• User help facilities
o integrated, context sensitive help versus add-on help
• Error information handling
o messages should be non-judgmental, describe problem precisely,
and suggest valid solutions
• Command labeling
o based on user vocabulary, simple grammar, and have consistent
rules for abbreviation
User Interface Evaluation Cycle
1. Preliminary design
2. Build first interface prototype
3. User evaluates interface
4. Evaluation studied by designer
5. Design modifications made
6. Build next prototype
7. If interface is not complete then go to step 3
User Interface Design Evaluation Criteria
• Length and complexity of written interface specification provide an
indication of amount of learning required by system users
• Number of user tasks and the average number of actions per task
provide an indication of interaction time and overall system efficiency
• Number of tasks, actions, and system states in the design model
provide an indication of the memory load required of system users
• Interface style, help facilities, and error handling protocols provide a
general indication of system complexity and the degree of acceptance
by the users
Data Design
• Data Design Principles o Systematic analysis principles applied to function and behavior
should also be applied to data. o All data structures and the operations to be performed on each
should be identified. o Data dictionary should be established and used to define both
data and program design. o Low level design processes should be deferred until late in the
design process. o Representations of data structure should be known only to those
modules that must make direct use of the data contained within in the data structure.
o A library of useful data structures and operations should be developed.
o A software design and its implementation language should support the specification and realization of abstract data types.
Component Level Design
• The purpose of component level design is to translate the
design model into operational software.
• Component level design occurs after the data,
architectural, and interface designs are established.
• Component-level design represents the software in a way
that allows the designer to review it for correctness and
consistency, before it is built.
• The work product produced is the procedural design for
each software component, represented using graphical,
tabular, or text-based notation
Procedural Design Notation
• Flowcharts
o arrows for flow of control, diamonds for decisions, rectangles for
processes
• Box diagrams
o also known as Nassi-Scheidnerman charts
• Decision table
o subsets of system conditions and actions are associated with
each other to define the rules for processing inputs and events
• Program Design Language
o PDL - structured English or pseudocode used to describe
processing details
Kriteria Penilaian Notasi Design
• Modularity
o notasi mendukung pengembangan perangkat lunak modular
• Overall simplicity
o mudah dipelajari, mudah digunakan, mudah untuk menulis
• Ease of editing
o mudah untuk memodifikasi representasi desain ketika perubahan diperlukan
• Machine readability
o notasi dapat menjadi masukan secara langsung ke dalam sistem pembangunan
• Maintainability
o pemeliharaan konfigurasi
Kriteria Penilaian Notasi Design (2)
• Structure enforcement
o memberlakukan penggunaan konstruksi pemrograman terstruktur
• Automatic processing
o memungkinkan desainer untuk memverifikasi kebenaran dan kualitas desain
• Data representation
o kemampuan untuk mewakili data lokal dan global secara langsung
• Logic verification
o verifikasi logika otomatis meningkatkan kecukupan pengujian
• Easily converted to program source code
o membuat kode generasi lebih cepat