Teknik Informatika S1 Rekayasa Perangkat Lunak Design

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 Transformasi dari Model Analisis ke Model Perancangan Design Process and Design Quality Design Concepts (Abstract, Architecture, Modularity, Information Hiding, Functional Hiding, Functional Independence, Refinement) Design Model

PSPEC A Design Note one or more ”components" in the software design 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 manufacturer model number type swing direction inserts lights type number weight opening mechanism implemented as a data structure

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 details of enter algorithm implemented with a "knowledge" of the object that is associated with enter

Stepwise Refinement open walk to door; reach for knob; open door; repeat until door opens turn knob clockwise; walk through; if knob doesn't turn, then close door. take key out; find correct key; insert in lock; endif pull/push door move out of way; end repeat

Modular Design

Functional Independence

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 low low 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 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: menganalisis efektivitas desain dalam memenuhi persyaratan yang dinyatakannya, mempertimbangkan alternatif arsitektur pada tahap ketika membuat perubahan desain masih relatif mudah, dan 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

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 decision-makers workers

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 Interface Design User Interface Design (Three Golden Rules) User Interface Analysis and Design Data Design 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 Inter-modular interface design External interface design 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 The human engineer establishes a user model The software engineer creates a design model The end-user develops a mental image or user’s mental model (system perception) The implementers create an implementation model The process User, task, and environment analysis and modeling Interface design Interface construction Interface validation

The Models User model end user profiles: Novice Knowledgeable, intermittent user, Knowledgeable, frequent users Design model incorporates data, architectural, interface, and procedural representations of the software User's model or system perception user's mental image of system Implementation model 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 Character-based reports Graphical displays Specialized information Source of content Generated by components Acquired from data store 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 time between the point at which user initiates some control action and the time when the system responds User help facilities integrated, context sensitive help versus add-on help Error information handling messages should be non-judgmental, describe problem precisely, and suggest valid solutions Command labeling based on user vocabulary, simple grammar, and have consistent rules for abbreviation

User Interface Evaluation Cycle Preliminary design Build first interface prototype User evaluates interface Evaluation studied by designer Design modifications made Build next prototype 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 Systematic analysis principles applied to function and behavior should also be applied to data. All data structures and the operations to be performed on each should be identified. Data dictionary should be established and used to define both data and program design. Low level design processes should be deferred until late in the design process. 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. A library of useful data structures and operations should be developed. 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 arrows for flow of control, diamonds for decisions, rectangles for processes Box diagrams also known as Nassi-Scheidnerman charts Decision table subsets of system conditions and actions are associated with each other to define the rules for processing inputs and events Program Design Language PDL - structured English or pseudocode used to describe processing details

Kriteria Penilaian Notasi Design Modularity notasi mendukung pengembangan perangkat lunak modular Overall simplicity mudah dipelajari, mudah digunakan, mudah untuk menulis Ease of editing mudah untuk memodifikasi representasi desain ketika perubahan diperlukan Machine readability notasi dapat menjadi masukan secara langsung ke dalam sistem pembangunan Maintainability pemeliharaan konfigurasi

Kriteria Penilaian Notasi Design (2) Structure enforcement memberlakukan penggunaan konstruksi pemrograman terstruktur Automatic processing memungkinkan desainer untuk memverifikasi kebenaran dan kualitas desain Data representation kemampuan untuk mewakili data lokal dan global secara langsung Logic verification verifikasi logika otomatis meningkatkan kecukupan pengujian Easily converted to program source code membuat kode generasi lebih cepat

TERIMA KASIH