design concept -...

Pertemuan 5Design Concept

Design Concept and Principle

Analysis to Design

Process S pecification (PS P EC )D ata O b ject D e scription p rocedura ld es ignEn tity-

R ela tio nsh ipD iagra m

D ata F lowD iagra m

D ata D iction ary

d es ign

in terfaced es ign

State-Tra nsitionD iagra m

C o ntro l S p ecification (CS P EC )

a rch itec tu ra ld es ign

d atad es ign

THE ANALYSIS MODEL THE DESIGN MODEL

Criteria of a good design

• Exhibits a hierarchical organization• Modular• Contain Both data and procedures• Lead to modules which exhibit independent functional characteristiccharacteristic

• Lead to interfaces which reduce complexity of modules interconnection and with external environment

d bl h d b d f b d• Derived using a repeatable method based on information obtained during analysis

Where Do We Begin?

modeling

Spec

PrototypePrototypemodeling

DesignDesign

Design Principles• The design process should not suffer from ‘tunnel vision.’

• The design should be traceable to the analysis model.

• The design should not reinvent the wheel.

• The design should “minimize the intellectual distance” [DAV95] between the software and the problem as it exists in the real world.

• The design should exhibit uniformity and integration.

Th d i h ld b t t d t d t h • The design should be structured to accommodate change.

• The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered.

• Design is not coding, coding is not design. g g, g g

• The design should be assessed for quality as it is being created, not after the fact.

• The design should be reviewed to minimize conceptual (semantic) errors.

From Davis [DAV95]

Fundamental Concepts• abstraction—data, procedure, control

• refinement—elaboration of detail for all abstractions

• modularity—compartmentalization of data and function

• architecture—overall structure of the software• Structural properties• Extra‐structural properties• Styles and patternsy p

• procedure—the algorithms that achieve function

• hiding—controlled interfacesg

Data Abstraction

door

manufacturermodel numbertypeswing directioninsertslightslightstypenumber

weightopening 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 opensturn knob clockwise;

walk through;close door.

turn knob clockwise;if knob doesn't turn, thentake key out;find correct key;insert in lock;

endifendifpull/push doormove out of way;end repeat

Modularity of Designi t b ild i t h i t fieasier to build, easier to change, easier to fix ...

Modularity: Trade‐offsWh i h " i h " b f d l What is the "right" number of modules for a specific software design?

module development cost

cost ofsoftware

module

p

integrationcost

Region ofMinimum cost

optimal numberof modules

number of modules

Sizing Modules: Two Views

What's inside??

How big is it??

MODULE

Functional Independence

Functional Independence is achieved by developing Modules with specific subfunction of requirements and has simple interface when viewed from other parts of program structure.

COHESION ‐ the degree to which a

Functional independence is measured through :

gmodule performs one and only one function.

COUPLING th d t hi h COUPLING ‐ the degree to which a module is "connected" to other modules in the system.

Architecture“Th ll t t f th ft d th i hi h th t t t “The overall structure of the software and the ways in which that structure provides conceptual integrity for a system.” [SHA95a]

f f fStructural properties. defines the components of a system (e.g., modules, objects, filters) and the manner in which those components are packaged and interact with one another. For example, objects are packaged to encapsulate both data and the processing that manipulates the data and interact via the invocation of methods .

Extra‐functional properties. how the design architecture achieves requirements for performance, capacity, reliability, security, adaptability, and other system characteristics.

Families of related systems. draw upon repeatable patterns that are commonly encountered in the design of families of similar systems. In essence, the design should have the ability to reuse architectural building

blocks.

Information Hiding

modulemodulecontrolledcontrolled

• algorithm• algorithm

interfaceinterface • data structure• data structure

• details of external interface• details of external interface

• resource allocation policy• resource allocation policy

"secret""secret"clientsclients

a specific design decisiona specific design decision

Why Information Hiding?Why Information Hiding?• reduces the likelihood of “side effects”

limits the global impact of local design decisions• limits the global impact of local design decisions

• emphasizes communication through controlled interfaces

di th f l b l d t• discourages the use of global data

• leads to encapsulation—an attribute of high quality design

lt i hi h lit ft• results in higher quality software

Architectural Design

Why Architecture?

The architecture is not the operational software. Rather, it is a representation that enables a software engineer to:

(1) analyze the effectiveness of the design in meeting its stated requirements,

(2) consider architectural alternatives at a stage when making design changes is still relatively easy, and y y,

(3) reduce the risks associated with the construction of the software.

Data Design

• refine data objects and develop a set of data abstractions

• implement data object attributes as one or more data • implement data object attributes as one or more data structures

• review data structures to ensure that appropriate pp prelationships have been established

• simplify data structures as required

Data Design Principles

1. The systematic analysis principles applied to function and behavior should also be applied to data. 2 All data structures and the operations to be performed on each should be identified 2. All data structures and the operations to be performed on each should be identified. 3. A data dictionary should be established and used to define both data and program design. 4. Low level data design decisions should be deferred until late in the design process. Th t ti f d t t t h ld b k l t th d l th t 5. The representation of data structure should be known only to those modules that

must make direct use of the data contained within the structure. 6. A library of useful data structures and the operations that may be applied to them should be developed. 7. A software design and programming language should support the specification and realization of abstract data types.

Architectural StylesEach style describes a system category that encompasses: ]

(1) a set of components (e.g., a database, computational modules) that perform a function required by a system,

(2) a set of connectors that enable “communication, coordination and cooperation” among components components,

(3) constraints that define how components can be integrated to form the system, and

(4) semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts.

• Data‐centered architectures

• Data flow architectures

C ll d t hit t

y y g p p p

• Call and return architectures

• Object‐oriented architectures

• Layered architecturesy

Data‐Centered Architecture

Data Flow Architecture

Call and Return Architecture

Layered Architecture

An Architectural Design Method

"four bedrooms, three baths,lots of glass ..."

customer requirements

ots o g ass

architectural design

Deriving Program Architecture

ProgramProgramArchitecture

Partitioning the Architecture

• “horizontal” and “vertical” partitioning are required

Horizontal Partitioning

• define separate branches of the module hierarchy for each major function

• use control modules to coordinate communication between functions

function 1 function 3

function 2

Vertical Partitioning:FactoringFactoring

• design so that decision making and work are stratified

• decision making modules should reside at the top of the architecture

decision‐makersdecision makers

workers

Why Partitioned Architecture?

l i f h i i i i d • results in software that is easier to test, maintain and extend

• results in propagation of fewer side effects• results in propagation of fewer side effects

Structured Design

• objective: to derive a program architecture that is partitioned

approach• approach:• the DFD is mapped into a program architecture• the PSPEC and STD are used to indicate the content of each modulemodule

• notation: structure chart

Flow Characteristics

Transform flow

Transactionflow

General Mapping ApproachGeneral Mapping Approach

• isolate incoming and outgoing flow boundaries; for transaction flows, isolate the transaction center

• working from the boundary outward, map DFD transforms into corresponding modulesinto corresponding modules

• add control modules as required

fi th lt t t t i ff ti • refine the resultant program structure using effective modularity concepts

Transform Mapping

ab

d e f g h

i

data flow model

"Transform" mapping

c ij

x1 Transform mapping

x2 x3 x4

b c d e f g i

a h j

Factoring

typical "decision making" modules

direction of increasing decision making

making modules

typical "worker" modules

First Level Factoringg

main main programcontroller

inputcontroller

processingcontroller

outputcontroller

Second Level Mapping

DC

main

B A

A

control

CB

DDmapping from the flow boundary outward

Transaction Flowincoming flow

action path

T

p

Transaction Example

fixture setting fixtureservos

operatorcommands

processoperator commands

report

robot control

displayscreen

robot control

robotcontrolsoftware

assembly

in reality, other commandswould also be shown

asse b yrecord

Transaction Mapping PrinciplesTransaction Mapping Principles

• isolate the incoming flow path

• define each of the action paths by looking for the "spokes of the wheel"

• assess the flow on each action path

• define the dispatch and control structure

• map each action path flow individually

Transaction Mappinge fa

bt

de f

g h

i

k

data flow model jl

mn Mappingx1

b

a

t

x2

d e f

x3

g h x3.1

x4

l m nd e f g h x3.1

i j

k

Map the Flow Model

process operator

commands

command input

controller

determine type

read command

validate command

produce error

message

fixture status

controller

report generation controller

send control value

each of the action paths must be expanded further

Refining the Structure Chartprocess operator

commands

command input

controller

read validate produce

determine type

sendfixture reportread command

validate command

produce error

message

send control value

fixture status

controller

report generation controller

read fixture status

determine setting

format setting

read record

calculate output values

format report

User Interface Design

Golden Rules

• Place the user in control

• Reduce the user’s memory load

• Make the interface consistent

Place the User in Control

Define interaction modes in a way that does not force a user into unnecessary or undesired actions.

Provide for flexible interaction.

Allow user interaction to be interruptible and undoable.

Streamline interaction as skill levels advance and allow the interaction to be customized.

Hide technical internals from the casual user.

Design for direct interaction with objects that appear on the screen.

Reduce the User’s Memory Load

Reduce demand on short‐term memory.

Establish meaningful defaults. stab s ea g u de au ts

Define shortcuts that are intuitive.

The visual layout of the interface should be based on a real world metaphor.

Disclose information in a progressive fashion.

Make the Interface Consistent

Allow the user to put the current task into a meaningful context.

Maintain consistency across a family of applications.

If past interactive models have created user expectations, do not make changes unless there is a compelling reason to do so.

Interface Are Designed

• Inter modular interface design• driven by data flow between modules

• external interface design• driven by interface between applications• driven by interface between software and non‐human producers and/or y p /consumers of information

• human‐computer interface design• driven by the communication between human and machinedriven by the communication between human and machine

Type of User

• Novice : no syntactic knowledge of the system and little semantic knowledge of the computer application in general

• Knowledgeable, intermittent user : low syntactic knowledge of the system and reasonable semantic knowledge of the computer application pp

• Knowledgeable, frequent user : good syntactic and semantic knowledge

Interface design model

• Design model : created by software engineer, consists of data, architecture, interface, and procedures of the system

• User model : created by human engineer, depicts profile of end users of the system. E.g. : age, sex, education, etc

• System perception : image of the system that end user carries in y p p g yhis/her head

• System image : created by system implementers, manifestation of computer system with its syntax and semanticsp y y

Interface design issues

• Response time : length of response and variability of response time from average

• User help facility : integrated and add‐on

• Error information : understandable jargon, constructive advice for i i di ti f ti i t di i l i di t recovering, indication of negative impact, audio visual indicator, no

judgmental (never blame on user)

• Command labeling : command vs. windows oriented point and pickg p p

Interface design evaluation

Initial design UI Prototype 1

User evaluationUI

Prototype #n

Evaluation

yp

ModificationEvaluation assessment UI Complete

Interface design guidelinesGeneral InteractionGeneral Interaction

• Be consistent

• Give meaningful feedback

• Ask for verification of any non trivial destructive action : “ Are you sure..?”

• Permit easy reversal of most actions

• Reduce amount of information that must be memorized between actionf f

• Efficient in dialog, motion, and thought

• Forgive mistakes : protect system from error

C t i ti iti b f ti d i h di l• Categorize activities by function and organize screen geography accordingly

• Provide context sensitive help facilities

• Use simple verb phrases to name commands

Interface design guidelinesInformation DisplaInformation Display

• Display only relevant information to current context

• Use graphs/charts rather than tables

• Use consistent labels, standard abbreviations, and colors

• Allow maximum visual contact

• Produce meaningful error message

• Use windows to compartmentalize different types of information

Interface design guidelinesData Inp tData Input

• Minimum in number of user input actions

• Consistency between input and information display

• No inappropriate commands in every context

• Provide helps

• Simplify user in giving input format

Component‐Level Design

Procedural Design

• Used in structured programming

• Using graphical design notation : Flowchart

• Another option : Tabular Design Notation

Component‐Level Design

• the closest design activity to coding

• the approach:the approach:• review the design description for the component• use stepwise refinement to develop algorithm• use structured programming to implement procedural use structured programming to implement procedural logic

• use ‘formal methods’ to prove logic

Structured Programming for Procedural DesignDesign

• uses a limited set of logical constructs:• sequence• conditional — if‐then‐else, select‐case• loops —do‐while, repeat untilp , p

• leads to more readable, testable code

• important for achieving high quality but not enough• important for achieving high quality, but not enough

A Structured Procedural Designadd a condition Z,

a

x 1

x 2b c

if true, exit the program

x 2b

3x

c

d

ef

4

g

x

5

g

x

Program Design Language (PDL)if condition x

if then else

if condition x then process a; else process b; endif

PDLif-then-else PDL

easy to combine with source code machine readable no need for graphics inputmachine readable, no need for graphics input graphics can be generated from PDL enables declaration of data as well as procedureenables declaration of data as well as procedure easier to maintain

Why Design Language?

can be a derivative of the HOL of choice e.g., Ada PDL machine readable and processable can be embedded with source code, therefore easier to maintaintherefore easier to maintain can be represented in great detail, if designer and coder are different easy to review

DATA FLOW DIAGRAM

Konsep Perancangan TerstrukturKonsep Perancangan Terstruktur• Pendekatan perancangan terstruktur dimulai dari awal 1970.

• Pendekatan terstruktur dilengkapi dengan alat‐alat (tools) dan teknik‐teknik (techniques) yang dibutuhkan dalam pengembangan sistem, sehingga hasil akhir dari sistem yang dikembangkan akan diperoleh sistem yang strukturnya didefinisikan dengan baik dan jelas.g j

• Melalui pendekatan terstruktur, permasalahan yang komplek diorganisasi dapat dipecahkan dan hasil dari sistem akam mudah untuk dipelihara, fleksibel, lebih memuaskan pemakainya, mempunyai dokumentasi yang baik, tepat waktu, sesuai d bi b d i k k d k i i d dengan anggaran biaya pengembangan, dapat meningkatkan produktivitas dan kualitasnya akan lebih baik (bebas kesalahan)

Alasan Penggunaan ModelAlasan Penggunaan Model• Agar dapat fokus pada fitur‐fitur.

Agar dapat digunakan untuk melakukan perubahan dan perbaikan• Agar dapat digunakan untuk melakukan perubahan dan perbaikanterhadap user requirement dengan biaya dan resiko seminimal mungkin.

• Agar dapat digunakan untuk memverifikasi apakah pengembang telahg p g p p g gmemahami user environment dan telah mendokumentasikannya sehinggadapat digunakan oleh designer dan programmer dalam pengembangansistem.

(Yourdon, Edward. Modern Structured Analysis. Prentice‐Hall Inc., USA. : 132‐133)

Penggunaan Dataflow Diagram (DFD)Penggunaan Dataflow Diagram (DFD)

• Pertama kali digunakan sebagai notasi dalam software engineeringuntuk mempelajari isu isu seputar desain sistem [Yourdon & untuk mempelajari isu‐isu seputar desain sistem. [Yourdon & Constantine, 1975]

• Selanjutnya dipakai oleh para software engineer yang ingind lk i tmemodelkan user requirement.

• DFD digunakan oleh system analyst yang ingin fokus pada function‐oriented view.

• DFD tidak hanya digunakan untuk memodelkan information‐processing system namun dapat digunakan untuk memodelkanbusiness planning dan strategic planning.p g g p g

Data Flow Diagram• Data Flow Diagram (DFD) adalah alat pembuatan model yang memungkinkan profesional Data Flow Diagram (DFD) adalah alat pembuatan model yang memungkinkan profesional sistem untuk menggambarkan sistem sebagai suatu jaringan proses fungsional yang dihubungkan satu sama lain dengan alur data, baik secara manual maupun komputerisasi.

• DFD sering disebut juga dengan nama Bubble chart, Bubble diagram, model proses, diagram alur kerja, atau model fungsi.

• DFD ini adalah salah satu alat pembuatan model yang sering digunakan, khususnya bila fungsi‐fungsi sistem merupakan bagian yang lebih penting dan kompleks dari pada data yang dimanipulasi oleh sistemdimanipulasi oleh sistem.

• Dengan kata lain, DFD adalah alat pembuatan model yang memberikan penekanan hanya pada fungsi sistem.

• DFD ini merupakan alat perancangan sistem yang berorientasi pada alur data dengan konsep dekomposisi dapat digunakan untuk penggambaran analisa maupun rancangan sistem yang mudah dikomunikasikan oleh profesional sistem kepada pemakai maupun pembuat program.

Data Flow Diagram

• A data flow diagram (DFD) shows how data moves through an• A data flow diagram (DFD) shows how data moves through an information system but does not show program logic or processing steps

• A set of DFDs provides a logical model that shows what the t d t h it d itsystem does, not how it does it

71

Komponen‐komponen DFD

• Proses (process)

• Garis alir (flow)

• Simpanan (store)

• Terminator

Proses (Process)Proses (Process)• Proses adalah bagian dari sistem yang mentransformasikan inputmenjadi ouput[YOUR : 142].

Dii i k f k li j kk ” ” dil k k• Diisi kata, frase atau kalimat yang menunjukkan ”apa” yang dilakukan prosestersebut (verb‐object phrase).

Garis Alir (Flow)Garis Alir (Flow)• Garis alir digunakan untuk menggambarkan“aliran/pergerakan” data dari satu bagianaliran/pergerakan data dari satu bagiansistem ke bagian lainnya [YOUR : 143].

• Diisi nama dari paket data yang mengalir. Data dapat berpindah ke proses lain (sebagai input), ke simpanan (store) atau ke terminator.

• Jika menggunakan beberapa aliran data tidak• Jika menggunakan beberapa aliran data, tidakmenunjukkan urutan pemrosesan aliran data.

Simpanan (Store) 1 Simpanan (Store) – 1 • Simpanan digunakan untuk memodelkan paketdata yang “diam/istirahat” setelahmengalir data yang diam/istirahat setelahmengalir. Simpanan adalah pasif, data tidak akan berpindahjika tidak ada proses yang memintanya [YOUR : 149]149].

• Biasanya diisi nama yang menunjukkan bentuk“plural” dari paket data yang dibawa oleh garis alirdari dan ke luar simpanan.

Simpanan (Store) 2 Simpanan (Store) – 2

• Garis alir dari simpanan diinterpretasikan sebagai “read” atau“access” atau “retreive” informasi dari simpanan tersebut[YOUR : 153]. Misalkan simpanan data bernama Customeryang berisi informasi nama, alamat dan nomor telephone maka informasi yang diakses dapat berupa :

• single packet, contoh : mengakses sejumlah paket informasi yaitunama, alamat dan nomor telephone dari satu Customer.


• multiple packets, contoh : mengakses sejumlah paket informasi dariC t ti l di B d semuaCustomer yang tinggal di Bandung.

• portions of a packet, contoh : mengakses nomor telephone dari satuCustomer.

ti f l k t t h k t l h d i• portions of several packets, contoh : mengakses nomor telephone darisemuaCustomer yang tinggal di Bandung.


• Beberapa sistem analis tidak memberi nama garis alir darisimpanan.

• Jika garis alir tidak diberi label, maka artinya yang di‐aksesadalah seluruh paket informasi pada simpanan tersebutadalah seluruh paket informasi pada simpanan tersebut.

• Hal ini untuk penyederhanaan, terutama jika nama aliran data sama dengan paket data pada simpanan. g p p p


• Garis alir ke simpanan diinterpretasikan sebagai “write” atau“update” atau “delete” informasi ke simpanan tersebut[YOUR : 154]. Simpanan dirubah karena :

• Penambahan data baru pada simpanan• Penghapusan data pada simpanan• Modifikasi atau perubahan data pada simpanan

Terminator 1 Terminator – 1 • Terminator merepresentasikan entitas eksternal (external entities) yang berkomunikasi dengan sistem [YOUR : 155]berkomunikasi dengan sistem [YOUR : 155].

• Terminator dapat berupa seseorang atau sekelompok orang bahkansistem komputer di luar kontrol sistem yang dimodelkan namunberkomunikasi dengan sistem yang dimodelkan, misalnya : organisasi, pemerintahan, departemen, dalam perusahaan atau organisasi.

Terminator 2Terminator – 2

• Sangat mudahmengidentifikasi terminator karena biasanyaterminator adalah user dari sistem yang dimodelkan.

• Tiga hal penting terkait terminator [YOUR : 156] :T d t ”di l ” d i i t di d lk G i li d i• Terdapat ”di luar” dari sistem yang dimodelkan. Garis alir dariterminator ke sejumlah proses atau simpananmenunjukkan“interface” antara sistem dengan dunia luar.

Terminator 3Terminator – 3

• Tiga hal penting terkait terminator (lanjutan) :• Sebagai konsekuensi aturan pertama, system analyst atau system designer tidak diperbolehkanmengubah konten dari terminator ataucara terminator bekerja karena itu di luar sistem yang dimodelkan.

• Relasi antara terminator tidak diperbolehkan dimunculkan dalamDFD karena relasi tersebut bukanlah bagian dari sistem yang dimodelkan. Jika memang harus ditunjukkan adanya relasi antarterminator maka harus dimodelkan sebagai proses yang merupakanterminator, maka harus dimodelkan sebagai proses yang merupakanbagian dari sistem.

Diagram Konteks (Diagram Konteks (Context DiagramContext Diagram))

• Disebut juga Data Flow Diagram/DFD Level 0

• Adalah : diagram aliran data pada tingkat paling atas yang merupakanpenggambaran yang berfungsi untuk memperlihatkan interaksi /hubunganlangsung antara Sistem Informasi dengan lingkungannyalangsung antara Sistem Informasi dengan lingkungannya.

• DK menggambarkan sebuah sistem berupa sebuah proses yangDK menggambarkan sebuah sistem berupa sebuah proses yang berhubungan dengan satu atau beberapa entitas/entity.

83

Diagram Konteks Diagram Konteks (cont.)(cont.)

Karakteristik DK:Entitas : merupakan kelompok pemakai, organisasi atau sistem lain dimana sistemmelakukan komunikasi.

Proses yang dilakukan di dalam sistem

Input sistem (data yang diterima dari lingkungan)

Output sistem (data yang dialirkan oleh sistem ke luar)

Di luar sistem disebut lingkungan

84


Yang harus diperhatikan dalam DK:

• Antar Entitas tidak diperbolehkan komunikasi langsung

• Diperbolehkan untuk menggambarkan satu entitas lebih dari satu kali.

• Hindari dialog yang tidak perlu dalam diagram konteks

• Dialog yang perlu dalam diagram konteks harus dilakukan

85


• Kelompok pemakai dimana sistem itu akan digunakan harus diidentifikasisecara rinci, jangan sampai terlewat

• Kemungkinan kejadian-kejadian yang akan terjadi dalam penggunaan sistemharus diidentifikasi secara lengkap

• Arah anak panah yang menunjukkan aliran data jangan sampai terbalik agar p y g j j g p gdapat memberikan pemahaman yang benar terhadap seluruh proses sistemyang akan dibentuk

• Setiap kejadian digambarkan dalam bentuk tekstual yang sederhana danp j g y gmudah dipahami oleh pembuat sistem

86

Process 0 represents the entire grading systems

Unique reference number for each process

87

Context diagram for a grading system.

88Cara penggambaran yang lain

Data Flow DiagramData Flow Diagram (Diagram Alir Data)(Diagram Alir Data)[ DFD ] [ DAD ][ DFD ] [ DAD ][ DFD ] [ DAD ][ DFD ] [ DAD ]

• Pemodelan Diagram Konteks diturunkan ke EVENT LIST (Daftar Kejadian) = daftar kejadian yang terjadi dalam lingkungan dan mempunyai hubungan dengan respon yang diberikan sistem

• Hasil EVENT LIST diturunkan ke DFD / DAD yang berfungsi untuk membantu penggambaran DFD

89

Data Flow DiagramData Flow Diagram (cont.)(cont.)

• DFD/DAD adalah suatu alat pemodelan yang digunakan untukd lk f i d i i t b k i imemodelkan fungsi dari sistem, menggambarkan secara rinci

mengenai sistem sebagai jaringan kerja antar fungsi yang berhubungan satu sama lain dengan menunjukkan dari dan ke manad t li t idata mengalir serta penyimpanannya.

• Pada umumnya dimulai dari 0, 1, 2, dst. Level ke-0 disebut dengandiagram konteks yang menggambarkan sistem secara global

90

Data Flow DiagramData Flow Diagram (cont.)(cont.)

• Setiap penurunan ke level yang lebih rendah, yaitu 1, 2, dst makaproses-proses akan diurai lebih rinci dengan spesifikasi lebih jelas. proses proses akan diurai lebih rinci dengan spesifikasi lebih jelas. Disebut DFD levelled / DAD bertingkat

• DFD level terakhir yang tidak bisa di breakdown aliran data-nya• DFD level terakhir yang tidak bisa di breakdown, aliran data-nyadiberi penjelasan dengan kamus data (data dictionary)

DFD l l t khi tid k bi di h l i/ b kd• DFD level terakhir yang tidak bisa dipecah lagi/ breakdown, proses-nya diberi penjelasan dengan Spesifikasi Proses (Process Specification / PSPEC)

91

Komponen DFDKomponen DFDData Flow/Aliran data diwakili dengan tanda panahData Flow/Aliran data diwakili dengan tanda panah. Digunakan untuk menunjukkan pergerakan/aliran darikumpulan data/informasi dari satu bagian sistem kebagian sistem lainnya.

Data Storage / penyimpanan data. Merupakan bagian dariDAD yang digunakan untuk menunjukkan suatu kumpulan daripaket data

Proses, adalah bagian dari DAD yang merubah satu atau lebihmasukan menjadi keluaran-keluaran. Nama lainnya : bubble, function

Entitas, adalah seseorang atau sekelompok orang dalamsuatu kelompok organisasi atau departemen lain di dalamperusahaan. Dapat terdiri dari orang, unit terkait yang berinteraksi. Nama lain : terminator

92

Yang harus diperhatikanYang harus diperhatikan

ProsesProses

93

94

DFD Level 1

Data Dictionary 1 Data Dictionary – 1

• Data dictionary mendefinisikan elemen‐elemen data yaitu :• Menjelaskan aliran data dan simpanan dalam DFD.• Menjelaskan komposisi paket data yang terdapat dalam garis alirseperti paket kompleks (alamat customer) yang dapat dipecahmenjadi kota, negara, kode pos.

• Menjelaskan paket data dalam simpanan.• Menspesifikasikan nilai dan unit dari informasi dalam dataflow ataudata store.

• Menjelaskan rincian relasi antara simpanan yang nantinya akandigunakan dalam ERD.

Kamus Data Kamus Data (cont.)(cont.)

Hubungan DFD dan Kamus Data:Semua aliran data dalam DFD dan semua data store (penyimpanan data) harus didefinisikan dalam kamusdatadataSemua elemen data dan semua elemen data store harusterlihat dalam aliran data pada DFDterlihat dalam aliran data pada DFD

96


Isi Kamus Data:• Nama data• Nama data• Deskripsi data• Sumber/Source• Tujuan/Destination• Bentuk dan volume data• Struktur data (berisi elemen-elemen dan struktur dengan menggunakan

simbol-simbol dalam kamus data)

97


• Jumlah Kamus Data harus sesuai dengan jumlah aliran data pada DFD level terakhir

• Dapat Diuji dengan :− Apakah semua aliran data telah dideklarasikan dalam DFD?

A k h k l d t d h did fi i ik b i t h− Apakah semua komponen elemen data sudah didefinisikan sebagai contohkarakter valid?

− Apakah semua notasi yang digunakan sudah dikoreksi dengan benar?A k h ih d l d t tid k dij l k− Apakah masih ada elemen data yang tidak dijelaskan.

• Selanjutnya dari kamus data, dapat disusun pemodelan formulir.

98

Data Dictionary 2 Data Dictionary – 2 • Notasi data dictionary mendefinisikan elemen‐elemen data yaitu :

SimbolSimbol ArtiArti= Terdiri atas, mendefinisikan, diuraikan menjadi, artinya

+ Dan( ) Optional (pilihan boleh ada atau boleh tidak)( ) Optional (pilihan boleh ada atau boleh tidak){ } Pengulangan[ ] Memilih salah satu cara dari sejumlah alternatif, seleksi

* * Komentar@ Identifikasi atribut kunci| Pemisah sejumlah alternatif pilihan antara simbol [ ]

Data Dictionary 3 Data Dictionary – 3 • Contoh penggunaan notasi sebelumnya :

• nama gelar + nama pertama + • nama = gelar + nama_pertama + nama_tengah + nama_akhir

• gelar = [Drs. | Dra. | Ir. | dr. | Dr. | Professor]g | | | | |• nama_pertama = {legal‐character}• nama_tengah = {legal‐character}• nama_akhir = {legal‐character}• legal‐character = [A‐Z|a‐z|0‐9|’|‐| |]

Data Dictionary 4 Data Dictionary – 4

• Contoh penggunaan notasi sebelumnya :

tinggi = *unit: meter; range: 100‐200*

Jenis kelamin = *values: [P|L]*Jenis_kelamin = values: [P|L]

order = nama_customer + alamat_kirim + 1{item}10

Artinya bahwa order selalu mempunyai nama customer, alamat dimana order akan dikirim danmempunyaiArtinya bahwa order selalu mempunyai nama customer, alamat dimana order akan dikirim danmempunyaiitem pemesanan antara 1 sampai 10

Data Dictionary 5 Data Dictionary – 5 Isi Kamus Data :• Nama data

Nama Data Data_anggota• Nama data• Deskripsi data• Sumber/source

Deskripsi Data anggota yang harus diberikan jika ingin menjadi anggota perpustakaan

Struktur Data Data_anggota = nrp + nama + fakultas + (no telepon)

• Tujuan/destination• Bentuk dan volume data

(no_telepon)nrp = 7{0-9}nama = {karakter_legal}fakultas = [kedokteran| psikologi| teknik| IT]no telepon = {0-9}

• Struktur data (berisi elemen-elemen dan struktur denganmenggunakan simbol-simboldalam kamus data)

no_telepon {0 9}karakter_legal = [A-Z|a-z|0-9|’|-| |]

dalam kamus data)

Process Specification 1 Process Specification – 1

• Digunakan untuk mendeskripsikan proses yang terjadipada level paling rendah dari DFD

• Process specification (PSPEC) menjelaskan apa yang terjadipada setiap bottom level primitive bubble dalam DFD apapada setiap bottom‐level, primitive bubble dalam DFD, apayang dilakukan sehingga merubah inputmenjadi output.

Process SpecificationProcess Specification ((PSPECPSPEC))Hubungan DFD dan PSPEC:

Semua proses dalam DFD yang tidak dapat dipecah lagi harusdidefinisikan dalam PSPECdidefinisikan dalam PSPECAliran data masuk (input) dan keluar (otput) dalam DFD danhubungan ke data store harus sesuai dan relevan dalam PSPECSetiap elemen data dalam PSPEC harus:

Nama dari aliran data atau data storeAtau komponen dalam kamus data untuk suatu aliran data atauAtau komponen dalam kamus data untuk suatu aliran data ataudata store yang berhubungan dalam DFD

104

Process Specification 2 Process Specification – 2 • Syarat dari PSPEC :

1 Dapat diverifikasi oleh pemakai dan penganalisa sistem sehingga1. Dapat diverifikasi oleh pemakai dan penganalisa sistem, sehinggauser dan penganalis mengetahui isi dari proses

2. Mampu berkomunikasi secara efektif dari pemakai yang bervariasi. Umumnya para analis membuat PSPEC dengan bahasa Inggris

3 PSPEC dibuat ada yang sampai pada algoritma tetapi yang penting3. PSPEC dibuat ada yang sampai pada algoritma, tetapi yang pentingadalah memudahkan dalam pengimplementasian.

4. Untuk membuat hasil PSPEC yang bagus perlu didukung konstruksi-konstruksi, seperti :• IF then ELSE• DO CASE• DO WHILE• REPEAT UNTIL• Kalimat-kalimat linier (Aksi-aksi saja)( j )

Process Specification 3 Process Specification – 3 Isi PSPEC: Nomor 1.3.

Nama Cek Barang & Buat Daftar• Nomor Proses

• Nama ProsesDeskripsi Memeriksa barang yang dapat dijual dan membuat

daftarnya

Input Daftar barang yang mau dibeli

• Deskripsi Proses

• Masukan/Input

p g y gDaftar barang yang akan dijual

Output Daftar barang yang dapat dijual

Logika IF barang yang mau dibeli = barang yang mau dijual• Keluaran/Output

• Logika Proses

Logika IF barang yang mau dibeli = barang yang mau dijualTHENTambah list daftar barang yang dapat dijual

ERD dan DFDERD dan DFD

Semua data store dalam DFD harus sesuaidengan entitas atau relationship dari ERD Nama entitas ERD dan data store DFD harussesuai.

107

Tuntunan untuk Membangun DFDTuntunan untuk Membangun DFD

• Pilih nama yang bermakna baik bagi proses, garis alir, simpanan dan terminator.

• Penomoran proses.

• Hindari DFD yang terlalu kompleks.

• Gambar kembali DFD sampai memenuhi keperluan.

• Pastikan DFD konsisten baik secara internal maupun denganpemodelan lain.

Pilih Nama yang Bermakna Baik Bagi Proses, Garis Alir, SimpanandanTerminator – 1

• Pilih nama untuk proses yang menunjukkan fungsi yang dilakukan danbagaimana fungsi tersebut dilakukan.g g

• Jangan gunakan nama orang, karena nama orang bisa diganti jika “usang”, orang juga dapat melakukan beberapa pekerjaan dalam sistem jadi tidakpraktis menuliskannya berulang kali Lebih baik tentukan apa yang dilakukanpraktis menuliskannya berulang kali. Lebih baik tentukan apa yang dilakukan.


• Nama proses menggunakan verb (active verb/transitive verb) dan object.

• Contoh nama proses yang disarankan: • Menghitung diskon• Menampilkan laporan gudangp p g g• Validasi nomor telephone• Alokasi murid‐murid ke dalam kelas


• Contoh nama proses yang tidak disarankan : • Lakukan sesuatu• Fungsi lain‐lain• Input• Edit• Proses data• Hapus

• Penamaan untuk aliran data dan terminator pun demikian, harus bermaknabagi user. Contoh : jika menggunakan nama untuk sistem perbankanmaka

b h di h i l h b k dg j gg p

nama tersebut harus dipahami oleh orang‐orang perbankan pada umumnya.

• Hindari penggunaan frase yang mengarah ke programming‐oriented terminology, seperti : ROUTINE, PROCEDURE, FUNCTION, SUBSYSTEM kecuali usermengerti hal inikecuali usermengerti hal ini.

Penomoran ProsesPenomoran Proses

• Penomoran di DFD berurutan tapi tidak menunjukkan proses tersebut dilakukan berurutan karena DFD adalah model yang menunjukkan jaringan komunikasi, asynchronous processes.

• Adanya keterurutan antar proses dapat ditunjukkan oleh • Adanya keterurutan antar proses dapat ditunjukkan oleh aliran data, tapi bukan dengan nomor proses.

• Nomor dipakai untuk merujuk bubble atau sebagai basis p j gpemecahan level.

Hindari DFD yang Terlalu KompleksHindari DFD yang Terlalu Kompleks

• Tujuan DFD adalah memodelkan fungsi‐fungsi yang dilakukansebuah sistem dan interaksi antara fungsi tersebutsebuah sistem dan interaksi antara fungsi tersebut.

• Tapi DFD harus dapat dibaca, dipahami, enak dipandangmatabukan hanya oleh system analyst namun juga user.

• Janganmembuat DFD dengan terlalu banyak proses, garis alir, simpanan dan terminator.

Umumnya dalam satu diagram tidak diperbolekan lebih dari 6 • Umumnya, dalam satu diagram tidak diperbolekan lebih dari 6 proses (1/2 lusin) dan simpanan‐garis alir‐terminator yang terkaitatau harus muat dalam kertas standar 8.5 * 11 inch.

Gambar Kembali DFD sampai MemenuhiKeperluanKeperluan

• Gambar DFD berulang kali sampai• Secara teknis benar• Secara teknis benar• Diterima oleh user

• Hal‐hal yang perlu diperhatikan : y g p p• Ukuran dan bentuk bubble : lingkaran, oval, rectangle. Ukuran yang lebih besar tidakmenunjukkan proses mana lebih penting.

• Dataflow boleh berbentukmelengkung atau garislurus.

Pastikan DFD Konsisten Baik Secara Internal Maupun denganPemodelan Lain – 1

• DFD harus konsisten baik internal DFD‐nya itusendiri maupun dengan pemodelan lain sepertisendiri maupun dengan pemodelan lain sepertientity‐relationship diagram, state‐transition diagram, data dictionary dan process specification. Konsisten internal DFD diantaranya : Konsisten internal DFD diantaranya :

• Tidak diperbolehkan bubble yang punya input tapi tidakpunya output (black hole).


• Tidak diperbolehkan bubble yang punya ouput tapi tidak punya input, ki d li t k “ d b meskipun ada pengecualian untuk proses “random‐number

generator” misalnya.


• Perhatikan apakah ada aliran data dan proses yang tidak diberinama.

• Hati‐hati simpanan data yang “read‐only” atau “write‐only”. Simpanan data harus pernah diciptakan jika digunakan, begitu jugasebaliknya simpanan tidak hanya diciptakan tapi harus digunakansebaliknya simpanan tidak hanya diciptakan tapi harus digunakan.

Membuat Sejumlah Level DFD – 1

• Untuk apa gunanya membuat sejumlah level di DFD ? Agar tampilannya tidak seperti ini :

Membuat Sejumlah Level DFD 2 Membuat Sejumlah Level DFD – 2 • Membuat sejumlah level bermanfaat untuk melihatbermanfaat untuk melihatrincian proses di level tingkat sebelumnya yang masih lebih umummasih lebih umum.

Membuat Sejumlah Level DFD 3Membuat Sejumlah Level DFD – 3

• Sampai berapa banyak level harus dibuat ?• Setiap level tidak bolehmemuat lebih dari 6 proses atau harusmuat 1 halaman kertas.

• Pastikan satu proses dapat dijelaskan dalam Process p p jSpecification dan tidak terlalu kompleks.

• Berapa banyak level harus dibuat untuk satu sistem ?U t k i t d h bi i l l i t• Untuk sistem sederhana biasanya sampai 2‐3 level, sistemsedang 3‐6 level, sistem besar 5‐8 level.


• Apakah semua proses harus dipartisi ke dalam level detail yang sama, misalnya jika level 1 ada 5 proses, salah satu harusdipecah ke level 2, apakah ke‐4 proses lain harus dipecah juga?

• Tidak. Satu bagian sistem bisa lebih kompleks dari bagian sistemlainnya tapi tetap perhatikan keseimbangan jangan sampai adaproses yang berhenti di level 2 tapi proses lainnya berhenti di level 8.


• Bagaimana menunjukkan semua level di DFD kepada user ?• Tergantung jenis user‐nya :

• High‐level executive user biasanya hanya tertarik pada context diagram ataulevel 1.O ti l l l bi h i i lih t i t t• Operational‐level user biasanya hanya ingin melihat sistem yang menurutnyamenarik.


• Bagaimana memastikan bahwa antar level DFD konsisten satusama lain ?

• Dataflow yang masuk dan keluar dari bubble pada satu level harussama dengan dataflow yang masuk dan keluar di level pecahannya.

Bagaimana memastikan bahwa antar level DFD konsisten satu sama lain ?DFD konsisten satu sama lain ?

Membuat Sejumlah Level DFD 7Membuat Sejumlah Level DFD – 7• Bagaimana menyimpansimpanan pada sejumlahsimpanan pada sejumlahlevel ?

• Tampilkan simpanan di level tertinggi yang menunjukkantertinggi yang menunjukkansimpanan data tersebutinterface antara 2 bubbleatau lebih lalu gambark b li di i l l l kembali di setiap lower‐level yang menggambarkaninterface bubble tersebut.

Jenis Kesalahan Umum Mahasiswa (1)• Mayor :

• Level 0 sudah berisi simpanan data


• Level 1 menjelaskan proses per entitas


• Aliran data dari satu proses terus menyambung ke proses berikutnya tanpa henti, tidak ada terminatortanpa henti, tidak ada terminator

Jenis Kesalahan Umum Mahasiswa (4)(4)• Mayor :

• Level pecahan ada yang isinya hanya 1 proses

Jenis Kesalahan Umum Mahasiswa (5)(5)• Mayor :

• Entitas didaftarkan semuanya dari entitas yang ada di flowchart, meskipun tidak menerima input/output dari/ke sistemmeskipun tidak menerima input/output dari/ke sistem

• Pada aliran data tertulis proses, misalnya : “Menampilkan Pesan Error” atau “Output Data Anu...Anu...”

Jenis Kesalahan Umum Mahasiswa (6)( )• Mayor :

• Proses hanya menerima input, tidak pernah menghasilkan sesuatu• Proses hanya menghasilkan sesuatu, tidak pernah menerima sesuatu• Simpanan data tiba‐tiba ada tanpa pernah diciptakan

Jenis Kesalahan Umum Mahasiswa (7)Jenis Kesalahan Umum Mahasiswa (7)

• Mayor :• Jumlah antara simpanan data dan atau aliran data di DFD tidak sesuai dengan kamus data

• PSPEC hanya menjelaskan beberapa proses, bahkan ada yang menjelaskan di level tinggi padahal masih dipecah di level menjelaskan di level tinggi, padahal masih dipecah di level berikutnya

• Jumlah simpanan data tidak sesuai dengan ERD (ini terkait matkul Basdat)

• Minor : • Tidak teliti, jumlah aliran data di level sebelumnya <> dengan level berikutnyay

design concept -...

Documents