rekayasa perangkat lunakdinus.ac.id/repository/docs/ajar/10_11._design_-_rekayasa_perangkat... ·...

65
Teknik Informatika S1 Disusun Oleh: Egia Rosi Subhiyakto, M.Kom, M.CS Teknik Informatika UDINUS [email protected] +6281329571612 Design Rekayasa Perangkat Lunak

Upload: ngokhanh

Post on 13-Jul-2019

240 views

Category:

Documents


1 download

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

A Design Note

one or more ”components"

in the software design PSPEC Process SPECification

Transformasi dari Model Analisis ke Model

Perancangan

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

Modular Design

easier to build, easier to change, easier to fix ...

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

Data-Centered Architecture

Data Flow Architecture

Call and Return Architecture

Layered Architecture

Deriving Program Architecture

Program Architecture

Partitioning the Architecture

“Horizontal” and “vertical” partitioning are required

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

TERIMA KASIH