Software Design
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 elemenelemen 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
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
2.
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
ScheduleAlgorithm
RegistrationForm
RegistrationManager
addStudent(Course, StudentInfo)
RegistrationUser
name
Student
open()
addStudent(StudentInfo)
major
Professor
tenureStatus
Course
name
numberCredits
CourseOffering
location
open()
addStudent(StudentInfo)
Object diagrams
a Measurement
amount: 80
unit: 'bpm'
Billy: Patient
pulseRate:
PhenomenonType
a Measurement
amount: 74
unit: 'bpm'
a Measurement
amount: 5
unit: 'ft'
height:
PhenomenonType
John: Patient
a Measurement
amount: 6
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
Course
Course
Offering
Professor
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
Building
Library
Dorm
ERD Notation
One common form:
object1
(0, m)
relationship
(1, 1)
object 2
attribute
Another common form:
relationship
object1
(0, m)
object 2
(1, 1)
The ERD: An Example
NmDepan
Inisial
NmBlk
Nama
Gaji
nama
JenisKel
( 1,1 )
Pegawai
( 0,1
)
mengepalai
,N
(1
( 1,N)
( 1,1 )
lokasi
8
Departemen
JmlPegawai
T glMulai
)
(0,N
(0,1 )
(0,
N)
NoKT P
bekerja
untuk
nomor
( 0,N)
Alamat
mengatur
(1,
N)
( 1,1)
)
bekerja
pada
memimpin
menanggung
Proyek
( 1,1)
LamaJam
Nomor
T anggungan
Nama
Hubungan
JenisKel T glLahir
Nama
Lokasi
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
seleksi/pemilihan, dan iterasi.
urutan,
Student
Register
Pre-course
reading
Attend
classes
Attend
examination
Attend
class
Lecture
Tutorial
Practical
Receive
grade
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.
1: set course info
2: process
course form :
CourseForm
3: add course
: Registrar
theManager :
CurriculumManager
aCourse :
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
: Student
registration
form
registration
manager
math 101
math 101
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
Report.Create report
Cancel course
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 divideand-conquer and stepwise refinement, topdown 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;
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
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
controlled
interface
• algorithm
• 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
F4
F2
F3
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 operasioperasi 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. Bermacammacam 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