Pertemuan 5 Design Concept
Design Concept and Principle
Analysis to Design P r oce s s S pec ific a tio n (P S P E C )
D a ta O b jec t D e sc r iption E n tityR e la tio nsh ip D ia gr a m
procedural d e s ig n
D a ta F low D ia gr a m
D a ta D ic tion ar y
S ta te-Tr a ns itio n D iagr a m
C o ntro l S p ec ificat ion (C S P E C )
THE ANALYSIS MODEL
in te r fa c e d e s ig n a rc h ite c tu r a l d e s ig n d a ta d e s ig n
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 characteristic Lead to interfaces which reduce complexity of modules interconnection and with external environment d bl h db d f b d Derived using a repeatable method based on information obtained during analysis
Where Do We Begin?
modeling
Prototype Spec
Design
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 The design should be structured to accommodate change. d t h
•
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 patterns y p
•
procedure—the algorithms that achieve function
•
hiding—controlled interfaces g
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
Modularity of Design easier i tto build, b ild easier i tto change, h easier i tto fifix ...
Modularity: Trade‐offs What is the "right" number of modules Wh i h " i h " b f d l for a specific software design? module development cost p cost of software module integration cost
Region of Minimum cost
optimal number of modules
number of modules
Sizing Modules: Two Views What's inside??
MODULE
How big is it??
Functional Independence Functional Independence is achieved by developing Modules with specific sub function of requirements and has simple interface when viewed from other parts of program structure. Functional independence is measured through :
g COHESION ‐ the degree to which a module 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 “The overall structure of the software and the ways in which that structure “Th ll t t f th ft d th i hi h th t t t provides conceptual integrity for a system.” [SHA95a] f f f Structural 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 module controlled interface
• algorithm • data structure • details of external interface • resource allocation policy
clients
a specific design decision
"secret"
Why Information Hiding? •
reduces the likelihood of “side effects”
•
limits the global impact of local design decisions
•
emphasizes communication through controlled interfaces
•
di discourages the use of global data th f l b l d t
•
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 structures
•
review data structures to ensure that appropriate pp p relationships 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. 5. The representation of data structure should be known only to those modules that Th t ti f d t t t h ld b k l t th d l th t 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 Styles Each 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. y y g p p p •
Data‐centered architectures
•
Data flow architectures
•
C ll d t hit t Call and return architectures
•
Object‐oriented architectures
•
y Layered architectures
Data‐Centered Architecture
Data Flow Architecture
Call and Return Architecture
Layered Architecture
An Architectural Design Method customer requirements "four bedrooms, three baths, lots of glass ..." ots o g ass
architectural design
Deriving Program Architecture
Program Architecture
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 3
function 1
function 2
Vertical Partitioning: Factoring •
design so that decision making and work are stratified
•
decision making modules should reside at the top of the architecture
decision makers decision‐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
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 module
•
notation: structure chart
Flow Characteristics
Transform flow
Transaction flow
General 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 modules
•
add control modules as required
•
refine the resultant program structure using effective fi th lt t t t i ff ti modularity concepts
Transform Mapping a
b d
e
h
g
f
i
c
j
data flow model x1 x2 b
x4
x3 c
a
"Transform" Transform mapping
d
e
f
g
i
h
j
Factoring direction of increasing decision making
typical "decision making" modules making
typical "worker" modules
First Level Factoring g main program controller
input controller
processing controller
output controller
Second Level Mapping main
D C control
B
A A B C
mapping from the flow boundary outward
D
Transaction Flow incoming flow
action path p T
Transaction Example fixture setting
operator
fixture servos
commands process operator commands
report
display screen
robot control robot control software assembly asse by record
in reality, other commands would also be shown
Transaction 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 Mapping a
e
d
b t
f i
g
h
k
l
data flow model
j m n
x1
Mapping
t
b a
x3
x2 d
e
f
g
x4
h
l
x3.1 i
j k
m
n
Map the Flow Model process operator commands command input controller read command
validate command
determine type
produce error message
fixture status controller
report generation controller
each of the action paths must be expanded further
send control value
Refining the Structure Chart process operator commands command input controller read command
validate command
read fixture status
determine type
produce error message
determine setting
fixture status controller
format setting
report generation controller
read record
send control value
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 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 pp application
•
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 y p p : image of the system that end user carries in g y his/her head
•
System image : created by system implementers, manifestation of computer system with its syntax and semantics p 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 recovering, indication of negative impact, audio visual indicator, no i i di ti f ti i t di i l i di t judgmental (never blame on user)
•
Command labelingg : command vs. windows oriented point and pick p p
Interface design evaluation Initial design
UI Prototype 1
UI yp Prototype #n
User evaluation
Modification
Evaluation assessment
UI Complete
Interface design guidelines General 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 action f f
•
Efficient in dialog, motion, and thought
•
Forgive mistakes : protect system from error
•
C t Categorize activities by function and organize screen geography accordingly i ti iti b f ti d i h di l
•
Provide context sensitive help facilities
•
Use simple verb phrases to name commands
Interface design guidelines Information Display Information Displa
•
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 guidelines Data Inp t Data 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: • • • •
review the design description for the component use stepwise refinement to develop algorithm use structured programming to implement procedural logic use ‘formal methods’ to prove logic
Structured Programming for Procedural Design •
uses a limited set of logical constructs: • • •
sequence conditional — if‐then‐else, select‐case loops — p do‐while, repeat until , 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 Design add a condition Z, if true, exit the program
a x1 b
x2
x3
d f
e x4 g x5
c
Program Design Language (PDL)
if then else if-then-else
if condition x then process a; else process b; endif PDL
easy to combine with source code machine readable readable, no need for graphics input graphics can be generated from PDL enables 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 maintain can be represented in great detail, if designer and coder are different easy to review
DATA FLOW DIAGRAM
Konsep 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 dengan anggaran biaya pengembangan, dapat meningkatkan produktivitas dan bi b d i k k d k i i d kualitasnya akan lebih baik (bebas kesalahan)
Alasan Penggunaan Model •
Agar dapat fokus pada fitur‐fitur.
•
Agar dapat digunakan untuk melakukan perubahan dan perbaikan terhadap user requirement dengan biaya dan resiko seminimal mungkin.
•
Agar dapat g p digunakan g untuk memverifikasi apakah p pengembang p g g telah memahami user environment dan telah mendokumentasikannya sehingga dapat digunakan oleh designer dan programmer dalam pengembangan sistem. (Yourdon, Edward. Modern Structured Analysis. Prentice‐Hall Inc., USA. : 132‐133)
Penggunaan Dataflow Diagram (DFD) •
Pertama kali digunakan sebagai notasi dalam software engineering untuk mempelajari isu‐isu isu isu seputar desain sistem. [Yourdon & sistem [Yourdon & Constantine, 1975]
•
Selanjutnya dipakai oleh para software engineer yang ingin memodelkan d lk user requirement. i t
•
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 memodelkan p g dan strategic planning. g p g business planning
Data Flow Diagram •
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 sistem. dimanipulasi 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 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 h it d system does, nott how does it
71
Komponen‐komponen DFD •
Proses (process)
•
Garis alir (flow)
•
Simpanan (store)
•
Terminator
Proses (Process) • Proses adalah bagian dari sistem yang mentransformasikan input menjadi ouput [YOUR : 142]. •
Diisii kata, frase Dii k f atau kalimat k li yang menunjukkan j kk ”apa” yang dilakukan ” ” dil k k proses tersebut (verb‐object phrase).
Garis Alir (Flow) •
Garis alir digunakan untuk menggambarkan “aliran/pergerakan” data dari aliran/pergerakan data dari satu bagian sistem 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.
•
data tidak Jika menggunakan beberapa aliran data, tidak menunjukkan urutan pemrosesan aliran data.
Simpanan (Store) – (Store) 1 •
Simpanan digunakan untuk memodelkan paket data yang “diam/istirahat” setelah data yang diam/istirahat setelah mengalir. mengalir Simpanan adalah pasif, data tidak akan berpindah jika tidak ada proses yang memintanya [YOUR : 149]. 149]
•
Biasanya diisi nama yang menunjukkan bentuk “plural” dari paket data yang dibawa oleh garis alir dari dan ke luar simpanan.
Simpanan (Store) – (Store) 2 •
Garis alir dari simpanan diinterpretasikan sebagai “read” atau “access” atau “retreive” informasi dari simpanan tersebut [YOUR : 153]. Misalkan simpanan data bernama Customer yang berisi informasi nama, alamat dan nomor telephone maka informasi yang diakses dapat berupa : •
single packet, contoh : mengakses sejumlah paket informasi yaitu nama, alamat dan nomor telephone dari satu Customer.
Simpanan (Store) – (Store) 3 • • •
multiple packets, contoh : mengakses sejumlah paket informasi dari semua Customer yang tinggal C t ti l di Bandung. B d portions of a packet, contoh : mengakses nomor telephone dari satu Customer. portions of several packets, contoh ti f l k t t h : mengakses k nomor telephone dari t l h d i semua Customer yang tinggal di Bandung.
Simpanan (Store) – (Store) 4 •
Beberapa sistem analis tidak memberi nama garis alir dari simpanan.
•
Jika garis alir tidak diberi label, maka artinya yang di‐akses adalah seluruh paket informasi pada simpanan tersebut. tersebut
•
Hal ini untuk penyederhanaan, terutama jika nama aliran data sama dengan g p paket data pada p simpanan. p
Simpanan (Store) – (Store) 5 •
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 – •
Terminator merepresentasikan entitas eksternal (external entities) yang berkomunikasi dengan sistem [YOUR : 155]. [YOUR : 155]
•
Terminator dapat berupa seseorang atau sekelompok orang bahkan sistem komputer di luar kontrol sistem yang dimodelkan namun berkomunikasi dengan sistem yang dimodelkan, misalnya : organisasi, pemerintahan, departemen, dalam perusahaan atau organisasi.
Terminator 2 Terminator – •
Sangat mudah mengidentifikasi terminator karena biasanya terminator adalah user dari sistem yang dimodelkan.
•
Tiga hal penting terkait terminator [YOUR : 156] : •
Terdapat T d t ”di luar” dari l ” d i sistem i t yang dimodelkan. Garis di d lk G i alir li dari d i terminator ke sejumlah proses atau simpanan menunjukkan “interface” antara sistem dengan dunia luar.
Terminator 3 Terminator – •
Tiga hal penting terkait terminator (lanjutan) : •
•
Sebagai konsekuensi aturan pertama, system analyst atau system designer tidak diperbolehkan mengubah konten dari terminator atau cara terminator bekerja karena itu di luar sistem yang dimodelkan. Relasi antara terminator tidak diperbolehkan dimunculkan dalam DFD karena relasi tersebut bukanlah bagian dari sistem yang dimodelkan. Jika memang harus ditunjukkan adanya relasi antar terminator maka harus dimodelkan sebagai proses yang merupakan terminator, maka bagian dari sistem.
Diagram Konteks (Context (Context Diagram) Diagram) •
Disebut juga Data Flow Diagram/DFD Level 0
•
Adalah : diagram aliran data pada tingkat paling atas yang merupakan penggambaran yang berfungsi untuk memperlihatkan interaksi /hubungan langsung antara Sistem Informasi dengan lingkungannya. lingkungannya
•
DK menggambarkan sebuah sistem berupa sebuah proses yang berhubungan dengan satu atau beberapa entitas/entity.
83
Diagram Konteks (cont.) Karakteristik DK: Entitas : merupakan kelompok pemakai, melakukan komunikasi.
organisasi atau sistem lain dimana sistem
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
Diagram Konteks (cont.) 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
Diagram Konteks (cont.) •
Kelompok pemakai dimana sistem itu akan digunakan harus diidentifikasi secara rinci, jangan sampai terlewat
•
Kemungkinan kejadian-kejadian yang akan terjadi dalam penggunaan sistem harus diidentifikasi secara lengkap
•
g menunjukkan j g sampai p terbalik agar g Arah anak p panah y yang aliran data jjangan dapat memberikan pemahaman yang benar terhadap seluruh proses sistem yang akan dibentuk
•
Setiap digambarkan dalam bentuk tekstual yyang p kejadian j g g sederhana dan mudah dipahami oleh pembuat sistem
86
Process 0 represents the entire grading systems
Unique reference number for each process
Context diagram for a grading system. 87
Cara penggambaran yang lain
88
Data Flow Diagram (Diagram Alir Data) [ 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 Diagram (cont.) •
DFD/DAD adalah suatu alat pemodelan yang digunakan untuk memodelkan d lk fungsi f i dari d i sistem, i t menggambarkan b k secara rinci i i mengenai sistem sebagai jaringan kerja antar fungsi yang berhubungan satu sama lain dengan menunjukkan dari dan ke mana data d t mengalir li serta t penyimpanannya. i
•
Pada umumnya dimulai dari 0, 1, 2, dst. Level ke-0 disebut dengan diagram konteks yang menggambarkan sistem secara global
90
Data Flow Diagram (cont.) •
Setiap penurunan ke level yang lebih rendah, yaitu 1, 2, dst maka proses-proses proses proses akan diurai lebih rinci dengan spesifikasi lebih jelas. Disebut DFD levelled / DAD bertingkat
•
DFD level terakhir yang tidak bisa di breakdown, breakdown aliran data-nya diberi penjelasan dengan kamus data (data dictionary)
•
DFD llevell terakhir t khi yang tidak tid k bisa bi dipecah di h lagi/ l i/ breakdown, b kd prosesnya diberi penjelasan dengan Spesifikasi Proses (Process Specification / PSPEC)
91
Komponen DFD Data Flow/Aliran data diwakili dengan tanda panah. panah Digunakan untuk menunjukkan pergerakan/aliran dari kumpulan data/informasi dari satu bagian sistem ke bagian sistem lainnya. Data Storage / penyimpanan data. Merupakan bagian dari DAD yang digunakan untuk menunjukkan suatu kumpulan dari paket data Proses, adalah bagian dari DAD yang merubah satu atau lebih masukan menjadi keluaran-keluaran. Nama lainnya : bubble, function Entitas, adalah seseorang atau sekelompok orang dalam suatu kelompok organisasi atau departemen lain di dalam perusahaan. Dapat terdiri dari orang, unit terkait yang berinteraksi. Nama lain : terminator
92
Yang harus diperhatikan
Proses
Proses
93
DFD Level 1 94
Data Dictionary 1 Data Dictionary – •
Data dictionary mendefinisikan elemen‐elemen data yaitu : • •
• • •
Menjelaskan aliran data dan simpanan dalam DFD. Menjelaskan komposisi paket data yang terdapat dalam garis alir seperti paket kompleks (alamat customer) yang dapat dipecah menjadi kota, negara, kode pos. Menjelaskan paket data dalam simpanan. Menspesifikasikan nilai dan unit dari informasi dalam dataflow atau data store. Menjelaskan rincian relasi antara simpanan yang nantinya akan digunakan dalam ERD.
Kamus Data (cont.) Hubungan DFD dan Kamus Data:
Semua aliran data dalam DFD dan semua data store (penyimpanan data) harus didefinisikan dalam kamus data Semua elemen data dan semua elemen data store harus terlihat dalam aliran data pada DFD
96
Kamus Data (cont.) Isi Kamus 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
Kamus Data (cont.) •
Jumlah Kamus Data harus sesuai dengan jumlah aliran data pada DFD level terakhir
•
Dapat Diuji dengan : − Apakah semua aliran data telah dideklarasikan dalam DFD? − Apakah A k h semua komponen k elemen l d t sudah data d h didefinisikan did fi i ik sebagai b i contoh t h karakter valid? − Apakah semua notasi yang digunakan sudah dikoreksi dengan benar? − Apakah A k h masih ih ada d elemen l d t yang tidak data tid k dijelaskan. dij l k
•
Selanjutnya dari kamus data, dapat disusun pemodelan formulir.
98
Data Dictionary 2 Data Dictionary – •
Notasi data dictionary mendefinisikan elemen‐elemen data yaitu : Simbol
Arti
=
Terdiri atas, mendefinisikan, diuraikan menjadi, artinya
+
Dan
()
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 – •
Contoh penggunaan notasi sebelumnya : • nama nama = gelar gelar + nama_pertama + 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 – •
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 dan mempunyai item pemesanan antara 1 sampai 10
Data Dictionary 5 Data Dictionary – Isi Kamus Data : •
Nama data
•
Deskripsi data
•
Sumber/source
•
Tujuan/destination
•
Bentuk dan volume data
•
Struktur data (berisi elemenelemen dan struktur dengan menggunakan simbol-simbol dalam kamus data)
Nama Data
Data_anggota
Deskripsi
Data anggota yang harus diberikan jika ingin menjadi anggota perpustakaan
Struktur Data
Data_anggota = nrp + nama + fakultas + (no_telepon) (no telepon) nrp = 7{0-9} nama = {karakter_legal} fakultas = [kedokteran| psikologi| teknik| IT] no telepon = {0 {0-9} no_telepon 9} karakter_legal = [A-Z|a-z|0-9|’|-| |]
Process Specification 1 Process Specification – •
Digunakan untuk mendeskripsikan proses yang terjadi pada level paling rendah dari DFD
•
Process specification (PSPEC) menjelaskan apa yang terjadi pada setiap bottom‐level, bottom level primitive bubble dalam DFD, apa DFD apa yang dilakukan sehingga merubah input menjadi output.
Process Specification (PSPEC PSPEC)) Hubungan DFD dan PSPEC:
Semua proses dalam DFD yang tidak dapat dipecah lagi harus didefinisikan dalam PSPEC Aliran data masuk (input) dan keluar (otput) dalam DFD dan hubungan ke data store harus sesuai dan relevan dalam PSPEC Setiap elemen data dalam PSPEC harus: Nama dari aliran data atau data store Atau komponen dalam kamus data untuk suatu aliran data atau data store yang berhubungan dalam DFD
104
Process Specification 2 Process Specification – •
Syarat dari PSPEC : 1 1. 2. 3 3. 4.
Dapat diverifikasi oleh pemakai dan penganalisa sistem, sistem sehingga user dan penganalis mengetahui isi dari proses Mampu berkomunikasi secara efektif dari pemakai yang bervariasi. Umumnya para analis membuat PSPEC dengan bahasa Inggris PSPEC dibuat ada yang sampai pada algoritma, algoritma tetapi yang penting adalah memudahkan dalam pengimplementasian. Untuk membuat hasil PSPEC yang bagus perlu didukung konstruksikonstruksi, seperti : • • • • •
IF then ELSE DO CASE DO WHILE REPEAT UNTIL Kalimat-kalimat linier ((Aksi-aksi saja) j )
Process Specification 3 Process Specification – Isi PSPEC: •
Nomor Proses
•
Nama Proses
•
Deskripsi Proses
•
Masukan/Input
•
Keluaran/Output
•
Logika Proses
Nomor
1.3.
Nama
Cek Barang & Buat Daftar
Deskripsi
Memeriksa barang yang dapat dijual dan membuat daftarnya
p Input
Daftar
Output
Daftar barang yang dapat dijual
Logika
IF barang yang mau dibeli = barang yang mau dijual THEN Tambah list daftar barang yang dapat dijual
barang gy yang g mau dibeli Daftar barang yang akan dijual
ERD dan DFD Semua data store dalam DFD harus sesuai dengan entitas atau relationship dari ERD Nama entitas ERD dan data store DFD harus sesuai.
107
Tuntunan 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 dengan pemodelan lain.
Pilih Nama yang Bermakna Baik Bagi Proses, Garis Alir, Simpanan dan Terminator – 1 •
Pilih nama untuk proses yang menunjukkan fungsi yang dilakukan dan bagaimana g fungsi g tersebut dilakukan.
•
Jangan gunakan nama orang, karena nama orang bisa diganti jika “usang”, orang juga dapat melakukan beberapa pekerjaan dalam sistem jadi tidak praktis menuliskannya berulang kali. Lebih kali Lebih baik tentukan apa yang dilakukan. yang dilakukan
Pilih Nama yang Bermakna Baik Bagi Proses, Garis Alir, Simpanan dan Terminator – 2 •
Nama proses menggunakan verb (active verb/transitive verb) dan object.
•
Contoh nama proses yang disarankan: • • • •
Menghitung diskon p p g g Menampilkan laporan gudang Validasi nomor telephone Alokasi murid‐murid ke dalam kelas
Pilih Nama yang Bermakna Baik Bagi Proses, Garis Alir, Simpanan dan Terminator – 3 •
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 bermakna nama untuk sistem p perbankan maka bagi g user. Contoh : jika j menggunakan gg b harus h di h i oleh l h orang‐orang perbankan b k pada d umumnya. nama tersebut dipahami
•
Hindari penggunaan frase yang mengarah ke programming‐oriented terminology, seperti : ROUTINE, PROCEDURE, FUNCTION, SUBSYSTEM kecuali user mengerti hal ini. ini
Penomoran 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 aliran data, tapi bukan dengan nomor proses.
•
Nomor dipakai untuk merujuk bubble p j atau sebagai basis g pemecahan level.
Hindari DFD yang Terlalu Kompleks •
Tujuan DFD adalah memodelkan fungsi‐fungsi yang dilakukan sebuah sistem dan interaksi antara fungsi tersebut. tersebut
•
Tapi DFD harus dapat dibaca, dipahami, enak dipandang mata bukan hanya oleh system analyst namun juga user.
•
Jangan membuat DFD dengan terlalu banyak proses, garis alir, simpanan dan terminator.
•
Umumnya, dalam Umumnya dalam satu diagram tidak diperbolekan lebih dari 6 proses (1/2 lusin) dan simpanan‐garis alir‐terminator yang terkait atau harus muat dalam kertas standar 8.5 * 11 inch.
Gambar Kembali DFD sampai Memenuhi Keperluan •
Gambar DFD berulang kali sampai • •
•
Secara teknis benar Diterima oleh user
gp p Hal‐hal yyang perlu diperhatikan : •
•
Ukuran dan bentuk bubble : lingkaran, oval, rectangle. Ukuran yang lebih besar tidak menunjukkan proses mana lebih penting. Dataflow boleh berbentuk melengkung atau garis lurus.
Pastikan DFD Konsisten Baik Secara Internal Maupun dengan Pemodelan Lain – 1 •
DFD harus konsisten baik internal DFD‐nya itu sendiri maupun dengan pemodelan lain seperti entity‐relationship diagram, state‐transition diagram, data dictionary dan process specification. Konsisten internal DFD diantaranya : •
Tidak diperbolehkan bubble yang punya input tapi tidak punya output (black hole).
Pastikan DFD Konsisten Baik Secara Internal Maupun dengan Pemodelan Lain – 2 •
Tidak diperbolehkan bubble yang punya ouput tapi tidak punya input, meskipun ki ada d pengecualian li untuk t k proses “random‐number “ d b generator” misalnya.
Pastikan DFD Konsisten Baik Secara Internal Maupun dengan Pemodelan Lain – 3 • •
Perhatikan apakah ada aliran data dan proses yang tidak diberi nama. Hati‐hati simpanan data yang “read‐only” atau “write‐only”. Simpanan data harus pernah diciptakan jika digunakan, begitu juga sebaliknya simpanan tidak hanya diciptakan tapi harus digunakan. digunakan
Membuat Sejumlah Level DFD – 1 •
Untuk apa gunanya membuat sejumlah level di DFD ? Agar tampilannya tidak seperti ini :
Membuat Sejumlah Level DFD – Level DFD 2 •
Membuat sejumlah level bermanfaat untuk melihat rincian proses di level tingkat sebelumnya yang masih lebih umum. umum
Membuat Sejumlah Level DFD – Level DFD 3 •
Sampai berapa banyak level harus dibuat ? • Setiap level tidak boleh memuat lebih dari 6 proses atau harus muat 1 halaman kertas. • Pastikan satu p proses dapat p dijelaskan j dalam Process Specification dan tidak terlalu kompleks.
•
Berapa banyak level harus dibuat untuk satu sistem ? • Untuk U t k sistem i t sederhana d h bi biasanya sampaii 2‐3 level, sistem l l i t sedang 3‐6 level, sistem besar 5‐8 level.
Membuat Sejumlah Level DFD – Level DFD 4 •
Apakah semua proses harus dipartisi ke dalam level detail yang sama, misalnya jika level 1 ada 5 proses, salah satu harus dipecah ke level 2, apakah ke‐4 proses lain harus dipecah juga? •
Tidak. Satu bagian sistem bisa lebih kompleks dari bagian sistem lainnya tapi tetap perhatikan keseimbangan jangan sampai ada proses yang berhenti di level 2 tapi proses lainnya berhenti di level 8.
Membuat Sejumlah Level DFD – Level DFD 5 •
Bagaimana menunjukkan semua level di DFD kepada user ? •
Tergantung jenis user‐nya : • •
High‐level executive user biasanya hanya tertarik pada context diagram atau level 1. O Operational‐level user ti l l l bi biasanya h hanya i i melihat ingin lih t sistem i t yang menurutnya t menarik.
Membuat Sejumlah Level DFD – Level DFD 6 •
Bagaimana memastikan bahwa antar level DFD konsisten satu sama lain ? •
Dataflow yang masuk dan keluar dari bubble pada satu level harus sama dengan dataflow yang masuk dan keluar di level pecahannya.
Bagaimana memastikan bahwa antar level DFD konsisten satu sama lain ?
Membuat Sejumlah Level DFD – Level DFD 7 •
Bagaimana menyimpan simpanan pada sejumlah level ? •
Tampilkan simpanan di level tertinggi yang menunjukkan simpanan data tersebut interface antara 2 bubble atau lebih lalu gambar k b li di setiap i lower‐level l l l kembali yang menggambarkan interface bubble tersebut.
Jenis Kesalahan Umum Mahasiswa (1) •
Mayor : •
Level 0 sudah berisi simpanan data
Jenis Kesalahan Umum Mahasiswa (2) •
Mayor : •
Level 1 menjelaskan proses per entitas
Jenis Kesalahan Umum Mahasiswa (3) •
Mayor : •
Aliran data dari satu proses terus menyambung ke proses berikutnya tanpa 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 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) •
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 berikutnya y
