Software Design

Complete Sesion

M Reza R I.,S.Kom,.M.T.I
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.
 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.
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 software’s
top-level structure dan mengorganisasi dan
mengidentifikasi berbagai komponen.
- Software detailed design : menggambarkan tiap
komponen secara cukup mendetail untuk
konstruksinya.
General Concepts design
 Software bukan satu-satunya media yang
melibatkan desain. Dalam pemahaman 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.
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
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
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
1.4.2. Coupling and cohesion
 Coupling didefinisikan sebagai kekuatan
hubungan antara module, sementara
cohesion didefinisikan bagaimana elemen-
elemen membuat modul tersebut saling
berkaitan.
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.
 1.4.4 Encapsulation
 Encapsulation adalah menyembunyikan
implementasi dari client, sehingga client hanya
tergantung pada interface
Ilustrasi Encapsulation
 Seorang Professor bisa megajar 4 class pada
semester depan
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.
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.
Key issue in software design

Aspect adalah bagian dari sebuah program

cross cut

Aspect bukan merupakan bagian dari software’s functional

decomposition, tetapi hanya sebagai properti.

Key issues mempunyai peran yang penting untuk developer untuk

membuat pilihan dan lebih mudah untuk menemukan solusi
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
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
 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)
 The importance of software
architecture

 Kenapa kita perlu mengembangkan arsitektur ?:

 Agar setiap orang bisa mengerti mengenai
sistem yang ada.
 Untuk membiarkan user bekerja secara
individual terhadap sebuah sistem
 Persiapan untuk perluasan system
 Menyediakan fasilitas reuse and reusability
 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 dikombinasikan

Architectural structures dapat disebut juga dengan architectural style

 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
 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
 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
 Architectural Style
Secara umum architectural Style di bedakan
menjadi 5 :
1. General Structure
contoh : layers , pipes, filters, blackboard
 Architectural Style
2. Distributed systems
contoh : client server,
threetiers, broker
3. Interactive systems
contoh : model view
controller
4. Adaptable systems
contoh: micro kernel
5. Other
contoh : batch, interpreters
 3.2 Design pattern
 Aspects yang berulang dalam desain disebut dengan design
patterns.
 pattern adalah suatu outline dari permasalahan yang
besar dirubah ke dalam suatu masalah yang lebih khusus,
sehingga dapat ditemukan pemecahaanya.
 A good pattern sebaiknya
 Seumum mungkin
 Mengandung solusi yang telah dibuktikan dan efektif

untuk menyelesaikan masalah

 Studying patterns is an effective way to learn from the
experience of others
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
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 dapat diperluas
dalam sekejap oleh spesifiksi plug-ins
Dikenal dengan nama hot spots
4. Software Design Quality Analysis
and Evaluation
 4.1. Quality Attributes
 4.2. Quality Analysis and Evaluation
Techniques
 4.3. Measures (Ukuran )
Quality Attributes
 membedakan run-time (performance,
security, availability, functionality, usability)
 tidak dapat membedakan run-time
(modifiability, portability, reusability,
integrability and testability)
 berhubungan dengan architecture’s qualities
(conceptual integrity, correctness and
completeness, buildability).
Quality Analysis and Evaluation
Techniques
 Software design reviews
 Static analysis
 Simulation and prototyping
Software design reviews
 teknik untuk memverifikasi dan memastikan
kualitas dari suatu design artifacts
 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
Simulation and prototyping
 dynamic techniques untuk mengevaluasi
suatu design
 Dengan cara simulasi atau membuat
prototype
Measures (Ukuran)
 Function-oriented (structured) design
measures
- Structure Chart
 Object-oriented design measures
- Class Diagrams
5. Software Design Notations
 5.1. Structural Descriptions (static view)
 5.2. Behavioral Descriptions (dynamic view)
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
Architecture description languages
(ADLs)
 bahasa yang digunakan untuk
mendeskripsikan suatu software architecture
dalam kaitannya dengan komponen dan
connector.
 Class & Object Diagrams

 digunakan untuk merepresentasikan satu set

class (dan object) dan hubungan timbal-balik
diantaranya.
Class Diagrams

RegistrationForm ScheduleAlgorithm

RegistrationManager
addStudent(Course, StudentInfo)
Course
name
RegistrationUser numberCredits
name
Student open()
addStudent(StudentInfo)
major

Professor
tenureStatus
CourseOffering
location
open()
addStudent(StudentInfo)
Object diagrams

a Measurement Billy: Patient a Measurement

amount: 80 amount: 5
unit: 'bpm' unit: 'ft'

pulseRate: height:
PhenomenonType PhenomenonType

a Measurement John: Patient a Measurement

amount: 74 amount: 6
unit: 'bpm' unit: 'ft'

 Relationship between specific objects

 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.
Register.exe
Billing.exe
Billing
System Registrar.exe

People.dll
User
Course.dll
Course
Courses.dll
People.dll
Student Professor
Course Course
Offering
Collaboration responsibilities cards
(CRCs)
 digunakan untuk menandakan nama dari
suatu komponen (class), responsibilities, dan
nama komponen lain yang terkait.
 Deployment Diagram
Deployment diagram menunjukkan kofigurasi run-time
processing nodes dan komponen yang bergantung padanya.

Registration Database

Main
Library Building

Dorm
 ERD Notation
One common form:

(0, m)
object1 relationship object 2
(1, 1)

attribute
Another common form:

object1 relationship
object 2
(0, m) (1, 1)
 The ERD: An Example
NmDepan Inisial NmBlk

Nama

Alamat Gaji nama nomor lokasi8

JenisKel bekerja
untuk
Pegawai Departemen
NoKTP
mengepalai

(0,N )
JmlPegawai
TglMulai
mengatur
bekerja
memimpin
pada

(1,1 )
menanggung
LamaJam Proyek
(1,1 )

Nomor Nama Lokasi

Tanggungan

Nama Hubungan
JenisKel TglLahir
Interface description languages (IDLs)

 HARUS digunakan oleh Client

dan server
 Adalah bahasa deskripsi
interface, bukan bahasa
pemrograman
 Jackson structure diagrams
 digunakan untuk mendeskripsikan data structure
di dalam kaitannya dengan urutan,
seleksi/pemilihan, dan iterasi.

Student

Pre-course Attend Attend Receive

Register
reading classes examination grade

Attend
class

Lecture Tutorial Practical

Structure Charts
 Hierarchical Decomposition Chart
 Menggambarkan pengorganisasian code
 Banyak mengikuti subroutine/function calls
 Structure Charts juga terdiri dari :
 parameters passed in/out of routines
 loop and condition indications
A Simple Structure Chart for the
Calculate Pay Amounts Module
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)
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
 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.
course form :
1: set course info CourseForm
2: process

: Registrar 3: add course

aCourse : theManager :
CurriculumManager
Course
4: new course
 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.
Simple Data Flow Diagram
Decision tables and diagrams
 digunakan untuk merepresentasikan
kombinasi complex dari suatu kondisi dan
aksi.
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
Common System Flowchart
Symbols
 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.
Sequence Diagram

registration registration math 101 math 101

: Student form manager section 1

1: fill in info
2: submit
3: add course(Sue, math 01)
4: are you open?
5: are you open?
6: add (Sue)
7: add (Sue)
Statechart Diagram

Add student[ Count < 10 ]

Initialization Add student / Set count = 0 Open

[ Count = 10 ] ^Course
Cancel course
Report.Create report

Cancelled Closed
Cancel course
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.
Program Design Language
(PDL) if condition x 
  then process a; 
  else process b; 
endif 
if-then-else PDL
easy to combine with source code

machine readable, no need for graphics input

graphics can be generated from PDL

enables declaration of data as well as procedure

easier to maintain
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
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.
Data Abstraction
door

manufacturer
model number
type
swing direction
inserts
lights
type
number
weight
opening mechanism

implemented as a data structure

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

module • algorithm
controlled
interface • data structure
• details of external interface

• resource allocation policy

clients "secret"

a specific design decision

Function-oriented (structured) Design

 Desain dengan unit fungsional yang

mengubah input menjadi output
Function-Oriented (structured) Design
 Secara tidak resmi dipraktekkan sejak
pemrograman dimulai
 Ribuan sistem telah dikembangkan dengan
pendekatan ini
 Didikukung oleh sebagian besar bahasa
pemrograman
A Function-oriented view of design

Shared memory

F1 F2 F3

F4 F5
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.
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).
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
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.
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.
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.
Component-based Design (CBD)

 Tujuan : Memungkinkan untuk meletakkan

software dalam skala besar secara
bersamaan.
 Contoh : Web browser plug-in, GUI builder