Software Design

Kata pengantar

Definisi design oleh IEEE6 10.12-90 adalah sebagai berikut :“proses pendefinisian arsitektur, komponen, interface dankarakteristik lain dari sistem atau komponen” dan “ hasil dariproses itu”. Di tampilkan sebagai proses, software designadalah aktivitas terus menerus dari software engineering yangmana software requirements dianalisa dalam rangka untukmenghasilkan deskripsi dari struktur internal software yangberperan sebagai basis untuk konstruksinya. Lebih pastinya,sebuah softaware design (hasilnya) harus dapatmendeskripsikan arsitektur software.Karenanya, bagaimanasoftware dipecah dan disusun menjadi komponen-komponen,dan tampilan antara komponen-komponen tersebut, harus jugadapat mendeskripsikan komponen pada tingkatan detil yangmenyediakan 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 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 architectureSoftware 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. Distributed systems

contoh : client server,

threetiers, broker

3. Interactive systems

contoh : model view

controller

4. Adapateble systems

contoh: micro kernel

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

RegistrationForm

RegistrationManager

Course

Student

CourseOfferingProfessor

addStudent(Course, StudentInfo)

namenumberCredits

open()addStudent(StudentInfo)

major

location

open()addStudent(StudentInfo)

tenureStatus

ScheduleAlgorithm

nameRegistrationUser

Object diagrams

a Measurement

amount: 80

unit: 'bpm'

Billy: Patient a Measurement

amount: 5

unit: 'ft'

a Measurement

amount: 74

unit: 'bpm'

John: Patient a Measurement

amount: 6

unit: 'ft'

pulseRate:

PhenomenonType

height:

PhenomenonType

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.

Course Course

Offering

Student Professor

Course.dllCourse

People.dllUser

Register.exeBilling.exe

Billing

System Registrar.exe

Courses.dll

People.dll

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

Library

Dorm

Main Building

ERD Notation

(0, m) (1, 1)

object objectrelationship1 2

One common form:

(0, m)

(1, 1)

object1 object2

relationship

Another common form:

attribute

The ERD: An Example

8lokasi

Pegawai Departemen

Proyek

Tanggungan

memimpin

(0,N

) (0,1)

menanggung

bekerja

pada

(0,N) mengatur

(1,1

)(0

,N)mengepalai

(0,1)

bekerja

untuk

Nama

NmDepan Inisial NmBlk

JenisKel

Alamat Gaji

NoKTP

NamaJenisKel TglLahir

Hubungan

Nomor Nama Lokasi

nama nomor

TglMulai

LamaJam

JmlPegawai

(1,N)(1,1)

(1,1)

(1,N)

(1,N)

(1,1

)

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 urutan,

seleksi/pemilihan, dan iterasi.

Pre-coursereading

Attendexamination

Attendclasses

RegisterReceivegrade

Attendclass

TutorialLecture Practical

Student

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.

: Registrar

course form : CourseForm

theManager : CurriculumManageraCourse :

Course

1: set course info2: process

3: add 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

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)

math 101 section 1

Statechart Diagram

Cancelled

Initialization Open

Closed

Add student / Set count = 0

Add student[ Count < 10 ]

Cancel course

Cancel course

[ Count = 10 ] ^CourseReport.Create report

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

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

implemented as a data structure

manufacturer

model number

type

swing direction

inserts

lights

type

number

weight

opening mechanism

Procedural Abstraction

open

implemented with a "knowledge" of the

object that is associated with enter

details of enter

algorithm

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

"secret"

• algorithm

• data structure

• details of external interface

• resource allocation policy

clients

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

F2F1 F3

F4 F5

Shared memory

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