Software Design

1
Software Design
2
Kata pengantar

• Definisi design oleh IEEE6 10.12-90 adalah
  sebagai berikut proses pendefinisian
  arsitektur, komponen, interface dan karakteristik
  lain dari sistem atau komponen dan hasil dari
  proses itu. Di tampilkan sebagai proses,
  software design adalah aktivitas terus menerus
  dari software engineering yang mana software
  requirements dianalisa dalam rangka untuk
  menghasilkan deskripsi dari struktur internal
  software yang berperan sebagai basis untuk
  konstruksinya. Lebih pastinya, sebuah softaware
  design (hasilnya) harus dapat mendeskripsikan
  arsitektur software.Karenanya, bagaimana software
  dipecah dan disusun menjadi komponen-komponen,
  dan tampilan antara komponen-komponen tersebut,
  harus juga dapat mendeskripsikan komponen pada
  tingkatan detil yang menyediakan konstruksi
  mereka.

3

• Software design memainkan peranan penting dalam
  membangun software. Software design mengijinkan
  software engineers untuk membuat beberapa model
  yang membentuk sejenis blueprint dari solusi
  menjadi implementasi.

4
Aktivitas Software design

• Dalam daftar standar software life cycle process
  seperti pada Software Life Cycle Processes,
  software design terdiri atas dua aktivitas yang
  sangat sesuai antara software requirements
  analysis dan software construction
• - Software architectural design(sering disebut
  toplevel design) Menggambarkan softwares
  top- level structure dan mengorganisasi dan
  mengidentifikasi berbagai komponen.
• - Software detailed design menggambarkan tiap
  komponen secara cukup mengijinkan untuk
  konstruksinya.

5
General Concepts design

• Software bukan satu-satunya media yang melibatkan
  desain. Dalam pemaham secara umum, kita dapat
  melihat desain sebagai bentuk pemecahan masalah.
  Sebagai contoh, kita mengambil konsep dari
  masalah yang tidak mempunyai solusi nyata, sangat
  menarik sebagai bagian untuk memahami batasan
  dari desain. Sejumlah ide dan konsep lain juga
  menarik untuk memahami desain dalam pemahaman
  umum tujuan, batasan, alternatif, representasi
  dan solusi.

6
Software Design Process

• Software design secara umum terdiri atas proses
  dua langkah
• - Architectural Design
• Architectural design mendeskripsikan bagaimana
  software dipecah dan disusun menjadi beberapa
  komponen (the software architecture)
• - Detailed Design
• Detailed design mendeskripsikan perilaku khusus
  komponen tersebut. Hasil dari proses tersebut
  merupakan kumpulan dari model-model dan artefak
  yang merekam keputusan utama yang telah diambil

7
1.4. Enabling Techniques

• Prinsip dari Software design , juga disebut
  dengan teknik penyediaan, adalah ide utama
  berdasarkan pada berbagai pendekatan dan konsep
  yang berbeda dari software design.
• Macam Enabling Techniques sebagai berikut
• Abstraction
• Coupling and cohesion
• Decomposition and modularization
• Encapsulation/information hiding
• Separation of interface and implementation
• Sufficiency, completeness and primitiveness

8
1.4.1 Abstraction

• Abstraction adalah karakteristik dasar dari
  sebuah entitas yang membedakan entitas tersebut
  dari entitas yang lain
• Abstraction mendefinisikan batasan dalam
  pandangan viewer
• Abstraction bukanlah pembuktian nyata,hanya
  menunjukkan intisari/pokok dari sesuatu

9
1.4.2. Coupling and cohesion

• Coupling didefinisikan sebagai kekuatan hubungan
  antara module, sementara cohesion didefinisikan
  bagaimana elemen-elemen membuat modul tersebut
  saling berkaitan.

10
1.4.3. Decomposition modularization

• Pendekomposisian dan pemodularisasian software
  besar menjadi sejumlah software independen yang
  lebih kecil, biasanya dengan tujuan untuk
  menempatkan fungsionalitas dan responsibilitas
  pada komponen yang berbeda.

11
1.4.4 Encapsulation

• Encapsulation adalah menyembunyikan implementasi
  dari client, sehingga client hanya tergantung
  pada interface

12
Ilustrasi Encapsulation

• Seorang Professor bisa megajar 4 class pada
  semester depan

13
1.4.5. Separation of interface and implementation

• Pemisahan interface dan implementasi melibatkan
  pendefinisian sebuah komponen melalui
  penspesifikasian sebuah public interface,
  diketahui oleh clients, terpisah dari detil
  bagaimana sebuah komponen direalisasikan.

14
1.4.6. Sufficiency, completeness and primitiveness

• Pencapaian ketercukupan, kelengkapan dan
  primitiveness, berarti memastikan bahwa komponen
  software menangkap semua karakteristik penting
  dari sebuah abstraksi dan tidak lebih.

15
(No Transcript)
16
Key issue in software design

• Aspect adalah bagian dari sebuah program cross
  cut
• Aspect bukan merupakan bagian dari softwares
  functional decomposition, tetapi hanya sebagai
  properti.
• Key issues mempunyai peran yang penting untuk
  developer untuk membuat pilihan dan lebih mudah
  untuk menemukan solusi

17
The number of key issues crosscutting

• Concurrency
• Bagaimana software dapat membedakan proses,
  task,threads, synchronisasi dan scheduling
• Control and handling of events
• Bagaimana sebuah software dapat mengatur data
  dan flow control
• Distribtions of components
• Bagaimana sebuah software dapat didistribusikan
  dan semua komponen saling berkomunikasi

18
The number of key issues crosscutting

• Error and Exception handling and Fault tolerance
• Bagaimana sebuah software dapat mengenali sebuah
  error dan mengetahui bagaimana cara mengatasinya
• Interaction and presentation
• Bagaimana sebuah software dapat berinteraksi
  dengan user dan dapat menampilkan keinginan user
• Data persistence
• Seberapa lama data akan disimpan

19

• Software architecture

• Software architecture adalah sebuah desain umum
  suatu proses pada sebuah software system.,
  meliputi
• Pembagaian software ke dalam subsistem
• Memutuskan bagaimana saling berhubungan
• Menentukan alat penghubung
• The structure of the components of a program
  /system, their interrelationships, and principles
  and guidelines governing their design and
  devolution over time (SEI software architecture
  discussion group)

20
The importance of software architecture

• Kenapa kita perlu mengembangkan arsitektur
• Agar setiap orang bisa mengerti mengenai sistem
  yang ada.
• Untuk membiarkan user bekerja secara indivial
  terhadap sebuah sistem
• Persiapan untuk perluasan system
• Menyediakan fasilitas reuse and reusability

21
3.1 Architectural Structures and view points

• View menampilkan aspek aspek yang terdapat pada
  software architecture yang menunjukan spesifikasi
  software.
• Architectural structures
• Sebuah sistem famili yag terkait dengan pattern
• sebuah vocabulary dari komponen dan connector
  type
• Suatu batasan dimana dapat kombinasikan
• Architectural tructures dapat disebut juga
  dengan architectural style

22
(No Transcript)
23
Architecture view

• Use Case View
• Analisa use case adalah teknik untuk meng-capture
  proses bisnis dari prespektif user.
• Aspek statis di-capture dalam use case diagram
• Aspek dinamis di-capture dalam interaction
  diagram, statechart diagram dan activity diagram
• Design View
• Meliputi class-class, interface, dan
  collaboration yang mendefinisikan vocabulary
  system
• Mendukung kebutuhan fungsional system
• Aspek statis di-capture dalam class diagram dan
  object diagram
• Aspek dinamis di-capture dalam interaction
  diagram, statechart diagram dan activity diagram

24
Architecture view

• Process View
• Meliputi thread dan pendefinisian proses-proses
  concurency dan syncronization
• Menunjukkan performance, scalability dan
  throughput
• Aspek statis dan dinamis di-capture dengan design
  view, tetapi lebih menekankan pada activ class
• Implementation View
• Meliputi komponen dan file yang digunakan untuk
  menghimpun dan me-release system physic
• Menunjukkan configuration management
• Aspek statis di-capture dalam component diagram
• Aspek dinamis di-capture dalam interaction
  diagram, statechart diagram dan activity diagram

25
Architecture view

• Deployment View
• Meliputi node yang membentuk topologi hardware
  system
• Menunjukkan pendistribusian, delivery, dan
  pengistallan
• Aspek statis di-capture dalam deployment diagram
• Aspek dinamis di-capture dalam interaction
  diagram, statechart diagram, activity diagram

26
Architectural Style

• Secara umum architectural Style di bedakan
  menjadi 5
• General Structure
• contoh layers , pipes, filters, blackboard

27
Architectural Style

• Distributed systems
• contoh client server, threetiers, broker
• Interactive systems
• contoh model view controller
• Adapateble systems
• contoh micro kernel
• Other
• contoh batch, interpreters

28
3.2 Design pattern

• Aspects yang berulang dalam desain disebut dengan
  design patterns.
• pattern is suatu outline dari permasalahan yang
  besar dirubah ke dalam suatu masalah yang lebih
  khusus, sehingga dapat ditemukan pemecahaanya.
• A good pattern should
• Seumum mungkin
• Mengandung solusi yang telah dibuktikan efektif
  untuk menyelesaikan masalah
• Studying patterns is an effective way to learn
  from the experience of others

29
Macam macam Pattern

• Creational patterns
• membuat sebuah object berdasarkan prototype yng
  dibuat terlebih dahulu
• contoh builder, factory, prototype, singelton
• Structural Pattern
• contoh adapter, bridge ,proxy
• Behavioral Pattern
• contoh command, visitors, iterator

30
3.3 Families of programs and Frameworks

• penggunaan kembali desain dari sebuah perangkat
  lunak untuk mendesain families dari perangkt
  lunak.
• Hal tersebut disebut juga software product line
• Framework adalah suatu sistem perangkat lunak
  yang lengkap dan dapa diperluas dalam sekejap
  oleh spesifiksi plug-ins
• Dikenal dengan nama hot spots

31
4. Software Design Quality Analysis and Evaluation

• 4.1. Quality Attributes
• 4.2. Quality Analysis and Evaluation Techniques
• 4.3. Measures (Ukuran )

32
Quality Attributes

• membedakan run-time (performance, security,
  availability, functionality, usability)
• tidak dapat membedakan run-time (modifiability,
  portability, reusability, integrability and
  testability)
• berhubungan dengan architectures qualities
  (conceptual integrity, correctness and
  completeness, buildability).

33
Quality Analysis and Evaluation Techniques

• Software design reviews
• Static analysis
• Simulation and prototyping

34
Software design reviews

• teknik untuk memverifikasi dan memastikan
  kualitas dari suatu design artifacts

35
Static Analysis

• formal atau semiformal static (non-executable)
  analysis yang dapat dipergunakan untuk
  mengevaluasi suatu design
• Menganalisis apa yang program akan lakukan tanpa
  benar2 mengeksekusinya

36
Simulation and prototyping

• dynamic techniques untuk mengevaluasi suatu
  design
• Dengan cara simulasi atau membuat prototype

37
Measures (Ukuran)

• Function-oriented (structured) design measures
• - Structure Chart
• Object-oriented design measures
• - Class Diagrams

38
5. Software Design Notations

• 5.1. Structural Descriptions (static view)
• 5.2. Behavioral Descriptions (dynamic view)

39
Structural Descriptions (static view)

• Architecture description languages (ADLs)
• Class and object diagrams
• Component diagrams
• Collaboration responsibilities cards (CRCs)
• Deployment diagrams
• Entity-relationship diagrams (ERDs)
• Interface description languages (IDLs)
• Jackson structure diagrams
• Structure charts

40
Architecture description languages (ADLs)

• bahasa yang digunakan untuk mendeskripsikan suatu
  software architecture dalam kaitannya dengan
  komponen dan connector.

41
Class Object Diagrams

• digunakan untuk merepresentasikan satu set class
  (dan object) dan hubungan timbal-balik
  diantaranya.

42
Class Diagrams
43
Object diagrams

• Relationship between specific objects

44
Component Diagram
Component diagrams adalah salah satu macam dari
diagram yang memodelkan physical aspek dari suatu
object-oriented system. Component diagram
menunjukkan ketergantungan diantara satu set
komponen.
45
Collaboration responsibilities cards (CRCs)

• digunakan untuk menandakan nama dari suatu
  komponen (class), responsibilities, dan nama
  komponen lain yang terkait.

46
Deployment Diagram
Deployment diagram menunjukkan kofigurasi
run-time processing nodes dan komponen yang
bergantung padanya.
47
ERD Notation
One common form
(0, m)
object
object
relationship
1
2
(1, 1)
attribute
Another common form
relationship
object
object
1
2
(1, 1)
(0, m)
48
The ERD An Example
49
Interface description languages (IDLs)

• MUST be used by both the client and server
• Is an interface description language not a
  programming language

50
Jackson structure diagrams

• digunakan untuk mendeskripsikan data structure di
  dalam kaitannya dengan urutan, seleksi/pemilihan,
  dan iterasi.

51
Structure Charts

• Hierarchical Decomposition Chart
• describes code organization
• most often follows subroutine/function calls
• Structure Charts also include
• parameters passed in/out of routines
• loop and condition indications
• Only left most occurrence detailed

52
A Simple Structure Chart for the Calculate Pay
Amounts Module
53
Behavioral Descriptions (dynamic view)

• Activity diagrams
• Collaboration diagrams
• Data flow diagrams (DFDs)
• Decision tables and diagrams
• Flowcharts and structured flowcharts
• Sequence diagrams
• State transition and statechart diagrams
• Formal specification languages
• Pseudo-code and program design languages (PDLs)

54
Activity Diagram

• Activity diagram di dalam model use case dapat
  digunakan untuk meng-capture aktivitas-aktivitas
  dalam sebuah use case
• Sebenarnya merupakan flowchart, yang menunjukkan
  aliran kontrol activity ke activity yang lain

55
(No Transcript)
56
Collaboration Diagram
Suatu collaboration diagram menekankan hubungan
object yang mengambil bagian dari suatu
interaksi.Tidak seperti sequence diagram, kita
tidak harus menunjukkan lifeline dari suatu
object explicitly dalam suatu collaboration
diagram. Urutan peristiwa ditandai oleh
angka-angka urutan pesan terlebih dahulu.
57
Data flow diagrams (DFDs)

• Data flow diagram (DFD) suatu model proses yang
  digunakan untuk melukiskan alir data melalui
  suatu sistem dan pekerjaan atau pengolahan yang
  dilakukan oleh sistem itu. Atau yang biasa
  disebut juga dengan bubble chart, transformation
  graph, and process model.

58
Simple Data Flow Diagram
59
Decision tables and diagrams

• digunakan untuk merepresentasikan kombinasi
  complex dari suatu kondisi dan aksi.

60
Flowcharts and structured flowcharts

• Penyajian berbagai program komputer, file,
  database, dan hubungan proses manual yang
  menjadikannya lengkap.
• menguraikan organisasi subsistem ke dalam
  komponen automated dan manual

61
Common System Flowchart Symbols
62
Sequence Diagram
Sequence diagram adalah suatu diagram interaksi
yang menekankan pada time ordering (waktu) pesan.
Ini menunjukkan satu set object dan pesan yang
diterima dan dikirim oleh object itu. Sequence
diagram adalah tabel yang menunjukkan object
pesan di sepanjang sumbu X, dan time ordering-nya
(waktu pemesanan) di sepanjang sumbu Y.
63
Sequence Diagram
64
Statechart Diagram
65
Formal Specification Language

• Mathematical formal yang didasarkan pada logika
  dengan pendukungan beberapa bahasa pemrograman
  (e.g. type system and parameterization)
• Merupakan non-executable models
• Dirancang untuk menetapkan apa yang akan dihitung
  dan bukan bagaimana perhitungan harus terpenuhi
• Bahasa formal didasarkan pada axiomatic set
  theory atau logika higher-order.

66
Program Design Language (PDL)
67
3.6 Software Design Strategies and Methods

• General Strategies
• Function-oriented (structured) Design
• Object-oriented Design
• Data-structure Centered Design
• Component-based Design (CBD)
• Other Methods

68
General Strategies

• Beberapa contoh dari kegunaan strategi umum dalam
  proses desain adalah divide-and-conquer and
  stepwise refinement, top-down vs bottom-up
  strategies, data abstraction and information
  hiding, use of heuristics, use of patterns and
  pattern languages, use of an iterative and
  incremental approach.

69
Divide and Conquer

• Trying to deal with something big all at once is
  normally much harder than dealing with a series
  of smaller things
• Separate people can work on each part.
• An individual software engineer can specialize.
• Each individual component is smaller, and
  therefore easier to understand.
• Parts can be replaced or changed without having
  to replace or extensively change other parts.

70
Data Abstraction
door
manufacturer
model number
type
swing direction
inserts
lights
type
number
weight
opening mechanism
implemented as a data structure
71
Procedural Abstraction
open
details of enter
algorithm
implemented with a "knowledge" of the
object that is associated with enter
72
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
73
Top-down and bottom-up designing

• Top-down design
• Start at the highest level (user interface).
• Work down to lower levels one-by-one.
• Do detailed decisions last (e.g., data formats,
  particular algorithms).
• Bottom-up design
• Make decisions about reusable low-level features
  first.
• Decide how these will be put together to create
  high-level constructs.

74
Information Hiding

• A useful definition of information hiding
• Potentially changeable design decisions are
  isolated (i.e., hidden) to minimize the impact
  of change.
• - David Parnas

75
Information Hiding
module
algorithm

controlled
data structure
interface

details of external interface

resource allocation policy
clients
"secret"
a specific design decision
76
Function-oriented (structured) Design

• Desain dengan unit fungsional yang mengubah input
  menjadi output

77
Function-oriented (structured) Design

• Secara tidak resmi dipraktekkan sejak pemrograman
  dimulai
• Ribuan sistem telah dikembangkan dengan
  pendekatan ini
• Didikukung oleh sebagian besar bahasa pemrograman

78
A Function-oriented view of design
79
A function-oriented view of design

• Merupakan Top-down design strategy atau desain
  terstruktur.
• Detail algoritma tersembunyi dalam sebuah fungsi,
  tetapi informasi state nya tidak. Jadi sebuah
  fungsi dapat mengganti state pada satu waktu
  tanpa mengganggu fungsi lain.
• Tidak umum bagi seseorang untuk sepenuhnya
  mengetahui bagaimana bagian-bagian berbeda dari
  sebuah program berinteraksi.

80
Object-oriented Design

• Banyak metode desain perangkat lunak yang
  berdasar pada object diusulkan. Bidang ini
  berkembang dari awal desain berbasis objek
  pertengahan tahun 1980an(kata benda objek, kata
  kerja metode, kata sifat atribut) sampai
  desain berorientasi objek, dimana pewarisan dan
  polymorphism memainkan peran kunci, ke bidang
  desain berbasis komponen, dimana meta-information
  dapat didefinisikan dan diakses (melalui
  refleksi, sebagai contohnya).

81
Characteristics of OOD

• Mengijinkan desainer untuk berpikir tentang
  interacting object yang memelihara state mereka
  sendiri dan menyediakan operasi-operasi pada
  state tersebut daripada sekumpulan fungsi yang
  beroperasi pada data yang di share.
• Objek hide information tentang representasi
  state, oleh karena itu aksesnya terbatas
• Objek mungkin terdistribusi dan dapat bekerja
  secara sekuensial ataupun paralel

82
Advantages of OOD

• Mudah pemeliharaannya. Objek dikenali sebagai
  entitas tersendiri.
• Objek adalah penggunaan kembali
  komponen-komponen.
• For some systems, there is an obvious mapping
  from real world entities to system objects.

83
Data-structure Centered Design

• Desain struktur data terpusat (contohnya, Jackson
  Warnier-Orr) mulai dari data menyusun manipulasi
  program lebih baik daripada yang dilakukan fungsi
  tersebut. Perencana software pertama-tama
  mendeskripsikan input dan output struktur data
  dan kemudian mengembangkan struktur kontrol
  program berdasar pada diagram struktur datanya.
  Bermacam-macam heuristik diusulkan penyelesaian
  dengan kasus tertentu sebagai contoh, saat
  terdapat mismatch antara input dan output
  sturktur.

84
Component-based Design (CBD)

• Sebuah komponen perangkat lunak adalah suatu unit
  yang independen, mempunyai definisi interface
  yang baik dan dependensi yang dapat disusun dan
  disebarkan secara independen. Desain berbasis
  komponen mengalamatkan isu yang terangkai dengan
  providing, developing, dan integrating seperti
  komponen untuk memperbaiki reuse.

85
Component-based Design (CBD)

• Tujuan Memungkinkan untuk meletakkan software
  dalam skala besar secara bersamaan.
• Contoh Web browser plug-in, GUI builder