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 mengijinkan untuk konstruksinya.
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.
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 indivial 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 kombinasikan
Architectural tructures 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.
3.
4. 5.
Distributed systems contoh : client server, threetiers, broker Interactive systems contoh : model view controller Adapateble systems contoh: micro kernel Other contoh : batch, interpreters
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
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 dapa 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 )
NoKTP
)
mengepalai
,N (1
( 1,N) ( 1,1)
lokasi 8
Departemen
JmlPegawai
TglMulai
)
(0,N
(0,1 )
(0 ,N
bekerja unt uk
nomor
(0,N)
Alamat
mengatur
( 1,
N)
(1,1)
) bekerja pada
memimpin
menanggung Proyek
(1,1)
LamaJam
Nomor Tanggungan
Nama
Hubungan JenisKel
TglLahir
Nama
Lokasi
Interface description languages (IDLs) MUST be used by both the
client and server Is an interface description language not a programming language
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
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
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-then-else
if condition x then process a; else process b; endif 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.
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.
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
a specific design decision
"secret"
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
