Teknik Informatika S1 Rekayasa Perangkat Lunak Design.

Presentasi berjudul: "Teknik Informatika S1 Rekayasa Perangkat Lunak Design."— Transcript presentasi:

1 Teknik Informatika S1 Rekayasa Perangkat Lunak Design

2 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)

3 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

4 PSPEC A Design Note one or more ”components" in the software design
Process SPECification

5 Transformasi dari Model Analisis ke Model Perancangan

6 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

7 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.

8 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

9 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.

10 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.

11 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.

12 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.

13 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.

14 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)

15 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.

16 Data Abstraction door manufacturer model number type swing direction
inserts lights type number weight opening mechanism implemented as a data structure

17 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.

18 Procedural Abstraction
open details of enter algorithm implemented with a "knowledge" of the object that is associated with enter

19 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

20 Modular Design

21 Functional Independence

22 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).

23 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.

24 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

25 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

26 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.

27 Architectural Styles Data-centered architectures
Data flow architectures Call and return architectures Object-oriented architectures Layered architectures

28 Data-Centered Architecture

29 Data Flow Architecture

30 Call and Return Architecture

31 Layered Architecture

32 Deriving Program Architecture

33 Partitioning the Architecture
“Horizontal” and “vertical” partitioning are required

34 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

35 Vertical Partitioning: Factoring
Pengambilan keputusan dan kerja yang bertingkat Pengambilan keputusan modul harus berada di atas arsitektur decision-makers workers

36 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.

37 Interface Design Interface Design
User Interface Design (Three Golden Rules) User Interface Analysis and Design Data Design Component Level Design

38 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.

39 Interface Design Fokus Interfaces Design  3 Area
Inter-modular interface design External interface design Human-Computer Interface (HCI) design

40 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.

41 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.

42 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

43 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

44 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

45 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

46 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

47 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

48 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

49 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

50 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

51 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

52 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

53 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

54 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

55 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

56 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

57 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

58 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

59

60 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.

61 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

62 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

63 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

64 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

65 TERIMA KASIH