TIM RPL Program Studi Teknik Informatika

Presentasi berjudul: "TIM RPL Program Studi Teknik Informatika"— Transcript presentasi:

1 TIM RPL Program Studi Teknik Informatika
Analysis Modeling (1) TIM RPL Program Studi Teknik Informatika

2 Kenapa Analisis Kebutuhan

3 Definisi Analisis Kebutuhan
“Penguraian kebutuhan-kebutuhan yang utuh ke dalam bagian-bagian komponennya dengan maksud untuk mengidetifikasikan dan mengevaluasi permasalahan dan hambatan sehingga dapat diusulkan perbaikan.”

4 Definisi Analisis Kebutuhan
Focus on What not How

5 Langkah-Langkah Analisis Kebutuhan
1. Identifikasi 2. Pemahaman 3. Pemodelan (Core of Analysis) 4. Pembuatan laporan

6 Langkah-Langkah Analisis Kebutuhan
1. Identifikasi Kegiatan yang bertujuan untuk memilih masalah mana yang akan dipecahkan dari kebutuhan yang didapat 2. Pemahaman Mempelajari prosedur manual yang akan digunakan sebagai dasar dalam pemodelan sistem

7 Langkah-Langkah Analisis Kebutuhan
3. Pemodelan (Core of Analysis) Membentuk hasil pemahaman kebutuhan menjadi model-model (alat bantu) analisis kebutuhan perangkat lunak yang nantinya akan digunakan sebagai dasar perancangan perangkat lunak 4. Pembuatan laporan Pembuatan laporan dengan format standar yang berisi hasil-hasil dari setiap langkah analisis kebutuhan

8 Pendekatan Analisis Kebutuhan
1. Pendekatan Analisis Terstruktur/ Process Oriented  RPL Pendekatan analisis yang berfokus pada rekayasa proses dan data 2. Pendekatan Analisis Berorientasi Objek/ OO  RPLL Pendekatan analisis yang berfokus pada rekayasa objek (atribut dan method) beserta relasinya

9 Definisi Analisis Terstruktur
Mengasumsikan data dan proses yang mengubah data sebagai entitas yang terpisah Objek data dimodelkan dengan cara mendefinisikan atribut dan relasi yang dimiliki Proses-proses yang memanipulasi objek data dimodelkan dengan cara menggambarkan bagaimana proses-proses tersebut mengubah data sebagai aliran objek melalui sistem

10 DFD (Data Flow Diagram)

11 Elemen DFD Empat unsur utama dari notasi DFD
Data Flow, dilengkapi dengan label untuk menunjukkan data apa yang mengalir Proses, yang menangani data Data store, berada di dalam sistem (diary, arsip atau berkas komputer) External/Outside entities/Terminator, sumber di luar data

12 Symbols Terminator/External Entities
Orang atau organisasi yang terletak di luar sistem dan pencetus atau penerima data. EMPLOYEE Key - outside the area of our concern and control.

13 Symbols Source (pencetus data) or sink (penerima data).
Sumber utama di sisi kiri dari DFD, selanjutnya di sisi kanan. Nama dalam kotak. Juga disebut entitas eksternal.

14 Symbols Data store (file) Sama seperti data store di kamus data.
Bisa berbentuk file computer, berkas kartu, lemari arsip, dll. Perhatikan bahwa EMPLOYEES di sini menyimpan data yang berisi informasi karyawan, sedangkan EMPLOYEE (terminator) adalah orang yang sebenarnya. Ukuran: sekitar 1 1/2 inch. EMPLOYEE

15 Symbols Process (bubble, transform) Sebuah aktifitas, tugas, fungsi.
Menunjukkan pekerjaan yang dilakukan terhadap data. Transformasi data masuk ke data keluar. Status perubahan (logical) atau isi, format, atau media (fisik). 1 PRODUCE- EMPLOYEE- PAYCHECK

16 Symbols Setiap proses memiliki nomor unik dan nama
Nama harus kata kerja aktif diikuti oleh klausa: EDIT-CUSTOMER-PAYMENT WRITE-PAYMENT-REPORT Jika tidak ada kata kerja aktif, itu bukan proses!

17 Symbols DATA-FLOW-NAME Data flow Antarmuka data antara bubbles, terminators, dan data stores. Berupa paket data yang terkait secara logis Baik--CUSTOMER-PAYMENT-TRANSACTION Buruk--MISCELLANEOUS-STUFF Tidak ada data berlebih yang dipakai *Tramp data tidak dapat diterima Data flow harus ramping dan punya arti. * Data yang disalurkan ke modul tetapi modulnya tidak memerlukan

18 Symbols Panah menunjukkan arah pergerakan data.
Masuk dan keluar dari data store Read from data store Write to data store EMPLOYEE Akses ke data store (request atau key) tidak ditampilkan, hanya hasilnya saja.

19 Symbols Naming (Penamaan) Unik, deskriptif.
Tentukan penamaan kamus data (karena semua nama perlu ada dalam kamus data juga). Tidak ada perulangan, jadi tidak pernah ada GET-NEXT-CUST. No flags. Hindari penamaan yang samar-samar seperti -INFO, -DATA. Real test--can you write a DD entry? Biasanya (tetapi tidak selalu) lebih spesifik. tes yang sesungguhnya - Anda dapat menulis Tambahkan entri?

20 Context Level DFD Bagian paling atas, sebagian besar pandangan abstrak sistem. Pandangan "Luar" sistem. Menunjukkan proses tunggal, input dan output dari seluruh sistem, dan terminator yang berkomunikasi. Tujuannya adalah untuk menggambarkan domain (ruang lingkup) dari sistem. Kadang-kadang disebut diagram level 0

21 Context Diagram PAYROLL-AUDIT-TRAIL EMPLOYEE-MAINTENANCE-AUDIT-TRAIL
MANAGEMENT EMPLOYEE-MAINTENANCE-TRANSACTION EMPLOYEE-HOURS-WORKED-TRANSACTION EMPLOYEE PAYROLL EMPLOYEE-PAY-RATE-TRANSACTION GENERAL-LEDGER-ACCOUNT-NUMBER EMPLOYEE-PAYCHECK GENERAL- LEDGER PAYROLL-VOUCHER PAYROLL-AUDIT-TRAIL

22 Context Diagram Clearly labeled “Context Diagram” Process bubble
Terminator Process bubble PAYROLL-AUDIT-TRAIL EMPLOYEE-MAINTENANCE-AUDIT-TRAIL MANAGEMENT EMPLOYEE-MAINTENANCE-TRANSACTION EMPLOYEE-HOURS-WORKED-TRANSACTION EMPLOYEE PAYROLL EMPLOYEE-PAY-RATE-TRANSACTION EMPLOYEE-PAY-RATE GENERAL-LEDGER-ACCOUNT-NUMBER EMPLOYEE-PAYCHECK GENERAL- LEDGER Data flows... PAYROLL-VOUCHER PAYROLL-AUDIT-TRAIL 22

23 Context Level DFD Kita akan membahas masing-masing komponen (bubble, data flow, data store, terminator)

24 Di sini, hanya satu, yang mewakili seluruh sistem.
Context Diagram Process bubbles Di sini, hanya satu, yang mewakili seluruh sistem. Bernomor 0, atau nomor dihilangkan. Ada sesuatu yang salah di sini? PAYROLL-AUDIT-TRAIL EMPLOYEE-MAINTENANCE-AUDIT-TRAIL MANAGEMENT EMPLOYEE-MAINTENANCE-TRANSACTION EMPLOYEE-HOURS-WORKED-TRANSACTION EMPLOYEE PAYROLL EMPLOYEE-PAY-RATE-TRANSACTION GENERAL-LEDGER-ACCOUNT-NUMBER EMPLOYEE-PAYCHECK GENERAL- LEDGER PAYROLL-VOUCHER PAYROLL-AUDIT-TRAIL 24

25 Remember, they are outside of our control.
Context Diagram Terminators Remember, they are outside of our control. In this case, each terminator is both a source and a sink. Prime sources on the left and prime sinks on the right. Can also show above and below. Shown here, then never again on lower levels. PAYROLL-AUDIT-TRAIL EMPLOYEE-MAINTENANCE-AUDIT-TRAIL MANAGEMENT EMPLOYEE-MAINTENANCE-TRANSACTION EMPLOYEE-HOURS-WORKED-TRANSACTION EMPLOYEE PAYROLL EMPLOYEE-PAY-RATE-TRANSACTION GENERAL-LEDGER-ACCOUNT-NUMBER EMPLOYEE-PAYCHECK GENERAL- LEDGER PAYROLL-VOUCHER PAYROLL-AUDIT-TRAIL 25

26 Bersifat internal untuk sistem, tidak ada level untuk ini
Context Diagram Data stores Bersifat internal untuk sistem, tidak ada level untuk ini PAYROLL-AUDIT-TRAIL EMPLOYEE-MAINTENANCE-AUDIT-TRAIL MANAGEMENT EMPLOYEE-MAINTENANCE-TRANSACTION EMPLOYEE-HOURS-WORKED-TRANSACTION EMPLOYEE PAYROLL EMPLOYEE-PAY-RATE-TRANSACTION GENERAL-LEDGER-ACCOUNT-NUMBER EMPLOYEE-PAYCHECK GENERAL- LEDGER PAYROLL-VOUCHER PAYROLL-AUDIT-TRAIL 26

27 Panjang, deskriptif, nama tunggal.
Context Diagram Data flows Panjang, deskriptif, nama tunggal. Sebuah "paket" dari data yang terkait secara logis. PAYROLL-AUDIT-TRAIL EMPLOYEE-MAINTENANCE-AUDIT-TRAIL MANAGEMENT EMPLOYEE-MAINTENANCE-TRANSACTION EMPLOYEE-HOURS-WORKED-TRANSACTION EMPLOYEE PAYROLL EMPLOYEE-PAY-RATE-TRANSACTION GENERAL-LEDGER-ACCOUNT-NUMBER EMPLOYEE-PAYCHECK GENERAL- LEDGER PAYROLL-VOUCHER PAYROLL-AUDIT-TRAIL 27

28 Adakah yang salah dengan ini?
Context Diagram Adakah yang salah dengan ini? PAYROLL-AUDIT-TRAIL EMPLOYEE-MAINTENANCE-AUDIT-TRAIL MANAGEMENT EMPLOYEE-MAINTENANCE-TRANSACTION EMPLOYEE-HOURS-WORKED-TRANSACTION EMPLOYEE PAYROLL EMPLOYEE-PAY-RATE-TRANSACTION GENERAL-LEDGER-ACCOUNT-NUMBER EMPLOYEE-PAYCHECK GENERAL- LEDGER PAYROLL-VOUCHER PAYROLL-AUDIT-TRAIL 28

29 Context Level DFD Duplicate data flow names acceptable if two or more identical copies of the same item going to two or more destinations. To show how the system relates to the world, we must show each copy. On level below, treat as a single data flow. Whether one or multiple copies is irrelevant except to outside world; we process the same regardless.

30 Leveling If a system is too large to be shown on a single diagram (aren't they all!), break into subsystems and sub-subsystems. Called leveling or top-down partitioning. Each partitioning (breaking up) of a bubble to a lower level is done to show more detail. Called an explosion in engineering terminology.

31 Leveling Parent/child relationship
A parent bubble can have a child diagram. How do we decide upon partitioning boundaries? Use the same techniques as when partitioning programs into subroutines.

32 Overview/Level 1 Diagram
Child of the single bubble on the Context Diagram. Shows major functions, major data stores and major data flows.

33 Overview / Level 1 Diagram
PAYROLL-AUDIT-TRAIL EMPLOYEE-HOURS-WORKED-TRANSACTION 1 PRODUCE- EMPLOYEE- PAYCHECK PAYROLL-VOUCHER GENERAL-LEDGER-ACCOUNT-NUMBER EMPLOYEE-PAYCHECK EMPLOYEE EMPLOYEE-MAINTENANCE-TRANSACTION 2 MAINTAIN- EMPLOYEE- RECORD EMPLOYEE-MAINTENANCE-AUDIT-TRAIL EMPLOYEE-PAY-RATE-TRANSACTION 33

34 Here, two major functions (bubbles).
Overview Diagram PAYROLL-AUDIT-TRAIL EMPLOYEE-HOURS-WORKED-TRANSACTION 1 PRODUCE- EMPLOYEE- PAYCHECK PAYROLL-VOUCHER GENERAL-LEDGER-ACCOUNT-NUMBER EMPLOYEE-PAYCHECK EMPLOYEE Process bubbles Here, two major functions (bubbles). May have up to seven bubbles on a diagram. What about 1 bubble? Numbered 1, 2, 3, etc. Names have an active verb & object clause. Avoid vague verbs like PROCESS. EMPLOYEE-MAINTENANCE-TRANSACTION 2 MAINTAIN- EMPLOYEE- RECORD EMPLOYEE-MAINTENANCE-AUDIT-TRAIL EMPLOYEE-PAY-RATE-TRANSACTION 34

35 Overview Diagram Partition the Overview Diagram based on:
Different major functions. Don’t put trivial functions (like EDIT, FORMAT, WRITE, etc.) on Overview. Different major inputs. Different time frames. Different equipment. Note: know all four of these criteria for tests.

36 Shown only on Context, so not here.
Overview Diagram PAYROLL-AUDIT-TRAIL EMPLOYEE-HOURS-WORKED-TRANSACTION 1 PRODUCE- EMPLOYEE- PAYCHECK PAYROLL-VOUCHER GENERAL-LEDGER-ACCOUNT-NUMBER EMPLOYEE-PAYCHECK Terminators Shown only on Context, so not here. EMPLOYEE EMPLOYEE-MAINTENANCE-TRANSACTION 2 MAINTAIN- EMPLOYEE- RECORD EMPLOYEE-MAINTENANCE-AUDIT-TRAIL EMPLOYEE-PAY-RATE-TRANSACTION 36

37 Unique, descriptive names, generally long.
Overview Diagram PAYROLL-AUDIT-TRAIL EMPLOYEE-HOURS-WORKED-TRANSACTION 1 PRODUCE- EMPLOYEE- PAYCHECK PAYROLL-VOUCHER GENERAL-LEDGER-ACCOUNT-NUMBER EMPLOYEE-PAYCHECK Data flows Unique, descriptive names, generally long. No reiteration, flags, or decisions. Show direction of data flow into/out of data stores. Read EMPLOYEES Write EMPLOYEE-MAINTENANCE-TRANSACTION 2 MAINTAIN- EMPLOYEE- RECORD EMPLOYEE-MAINTENANCE-AUDIT-TRAIL EMPLOYEE-PAY-RATE-TRANSACTION 37

38 Overview Diagram No labels on data flows into and out of data stores when using the entire record. Always need to use the entire record on a write, so writes are never labeled. On reads, if using just one or two fields, then label as such.

39 Overview Diagram Placement of data flows
Try to move left to right, top to bottom if possible. Inputs and outputs to edge of page. Avoid line crossings by rearranging.

40 Balancing A child diagram is balanced with a parent bubble if there are the same net inputs and outputs to the entire child diagram that there are to the parent bubble. Balancing is the foundation for the entire DFD system. Let’s check the balancing between the Context Diagram and the Overview Diagram...

41 Context Diagram 41 Overview Diagram EMPLOYEE EMPLOYEE GENERAL- LEDGER
MANAGEMENT PAYROLL EMPLOYEE-MAINTENANCE-TRANSACTION EMPLOYEE-HOURS-WORKED-TRANSACTION EMPLOYEE-PAYCHECK EMPLOYEE-PAY-RATE-TRANSACTION PAYROLL-AUDIT-TRAIL EMPLOYEE-MAINTENANCE-AUDIT-TRAIL PAYROLL-VOUCHER GENERAL-LEDGER-ACCOUNT-NUMBER Overview Diagram EMPLOYEE-HOURS-WORKED-TRANSACTION 1 PRODUCE- EMPLOYEE- PAYCHECK PAYROLL-AUDIT-TRAIL GENERAL-LEDGER-ACCOUNT-NUMBER PAYROLL-VOUCHER EMPLOYEE-PAYCHECK EMPLOYEE EMPLOYEE-MAINTENANCE-TRANSACTION 2 MAINTAIN- EMPLOYEE- RECORD EMPLOYEE-PAY-RATE-TRANSACTION EMPLOYEE-MAINTENANCE-AUDIT-TRAIL 41

42 Balancing 1st exception to balancing rule: multiple copies of same data flow don't violate balancing; they are logically the same data. On context, there were two PAYROLL-AUDIT-TRAILs. On lower level, treat logically and show just one copy.

43 Data Stores Data stores
Tricky rules governing where and when we create and show files.

44 Data Stores At what level do we show an existing file?
Show it for the first time at the highest level at which it is used by two or more bubbles. Then show all references to it. From then on, show it where it only when accessed. 2nd exception to the balancing rule: data stores that are shown at lower levels but not on the higher levels.

45 Data Stores Never show a data store on the context diagram.
What if used by only one bubble in entire system? Show at the very lowest level only.

46 Data Stores When should you create a data store from scratch?
When data must be delayed for some period of time. Example: collect transactions all day, then apply at night. When data must be used in a different order. Example: Data validation input files. A data store may be only interface between two or more bubbles.

47 Summary of the Overview Diagram
If we draw a big circle around the Overview Diagram, bisecting the inputs and outputs, then collapse the circle...

48 Overview Diagram 48 PAYROLL-AUDIT-TRAIL
EMPLOYEE-HOURS-WORKED-TRANSACTION 1 PRODUCE- EMPLOYEE- PAYCHECK PAYROLL-VOUCHER GENERAL-LEDGER-ACCOUNT-NUMBER EMPLOYEE-PAYCHECK EMPLOYEES EMPLOYEE-MAINTENANCE-TRANSACTION 2 MAINTAIN- EMPLOYEE- RECORD EMPLOYEE-MAINTENANCE-AUDIT-TRAIL EMPLOYEE-PAY-RATE-TRANSACTION 48

49 Context Diagram 49 PAYROLL-AUDIT-TRAIL
EMPLOYEE-MAINTENANCE-AUDIT-TRAIL MANAGEMENT EMPLOYEE-MAINTENANCE-TRANSACTION EMPLOYEE-HOURS-WORKED-TRANSACTION EMPLOYEE PAYROLL EMPLOYEE-PAY-RATE-TRANSACTION GENERAL-LEDGER-ACCOUNT-NUMBER EMPLOYEE-PAYCHECK GENERAL- LEDGER PAYROLL-VOUCHER PAYROLL-AUDIT-TRAIL 49

50 Diagram 1 Child of bubble 1 on Overview.
Diagram numbering: bubble 1 explodes to Diagram 1.

51 Diagram 1 51 EMPLOYEES EMPLOYEE-RECORD
EMPLOYEE-HOURS-WORKED-TRANSACTION 1.3 UPDATE- EMPLOYEE- RECORD 1.1 EDIT-HOURS- WORKED- TRANSACTION 1.2 CALCULATE- EMPLOYEE- PAYCHECK- AMOUNT PAYCHECK-AMOUNT VALID-HOURS- WORKED PAY-RATE 1.4 PRODUCE- EMPLOYEE- PAYCHECK EMPLOYEE-PAYCHECK EMPLOYEE- PAYCHECK- DETAIL PAYCHECK-AMOUNT PAYROLL-AUDIT-TRAIL 1.5 PRODUCE- REPORTING PAYROLL-VOUCHER GENERAL-LEDGER-ACCOUNT-NUMBER 51

52 Look at bubble functions…
Diagram 1 EMPLOYEES EMPLOYEE-RECORD EMPLOYEE-HOURS-WORKED-TRANSACTION 1.3 UPDATE- EMPLOYEE- RECORD 1.1 EDIT-HOURS- WORKED- TRANSACTION 1.2 CALCULATE- EMPLOYEE- PAYCHECK- AMOUNT PAYCHECK-AMOUNT VALID-HOURS-WORKED Process bubbles Numbering: each bubble number consists of the diagram number, a decimal, and a local number. Look at bubble functions… PAY-RATE 1.4 PRODUCE- EMPLOYEE- PAYCHECK EMPLOYEE-PAYCHECK EMPLOYEE- PAYCHECK- DETAIL PAYCHECK-AMOUNT PAYROLL-AUDIT-TRAIL 1.5 PRODUCE- REPORTING PAYROLL-VOUCHER GENERAL-LEDGER-ACCOUNT-NUMBER 52

53 Diagram 1 53 EMPLOYEES EMPLOYEE-RECORD
EMPLOYEE-HOURS-WORKED-TRANSACTION 1.3 UPDATE- EMPLOYEE- RECORD 1.1 EDIT-HOURS- WORKED- TRANSACTION 1.2 CALCULATE- EMPLOYEE- PAYCHECK- AMOUNT PAYCHECK-AMOUNT VALID-HOURS-WORKED PAY-RATE 1.4 PRODUCE- EMPLOYEE- PAYCHECK EMPLOYEE-PAYCHECK EMPLOYEE- PAYCHECK- DETAIL PAYCHECK-AMOUNT PAYROLL-AUDIT-TRAIL 1.5 PRODUCE- REPORTING PAYROLL-VOUCHER GENERAL-LEDGER-ACCOUNT-NUMBER 53

54 There can be multiple ways of partitioning.
Diagram 1 EMPLOYEES EMPLOYEE-RECORD EMPLOYEE-HOURS-WORKED-TRANSACTION 1.3 UPDATE- EMPLOYEE- RECORD 1.1 EDIT-HOURS- WORKED- TRANSACTION 1.2 CALCULATE- EMPLOYEE- PAYCHECK- AMOUNT PAYCHECK-AMOUNT VALID-HOURS-WORKED PAY-RATE Process bubbles There can be multiple ways of partitioning. Example: Combine 1.4 and 1.5 into one bubble on this level. 1.4 PRODUCE- EMPLOYEE- PAYCHECK EMPLOYEE-PAYCHECK EMPLOYEE- PAYCHECK- DETAIL PAYCHECK-AMOUNT PAYROLL-AUDIT-TRAIL 1.5 PRODUCE- REPORTING PAYROLL-VOUCHER GENERAL-LEDGER-ACCOUNT-NUMBER 54

55 EMPLOYEES shown again because accessed again.
Diagram 1 EMPLOYEES EMPLOYEE-RECORD EMPLOYEE-HOURS-WORKED-TRANSACTION 1.3 UPDATE- EMPLOYEE- RECORD 1.1 EDIT-HOURS- WORKED- TRANSACTION 1.2 CALCULATE- EMPLOYEE- PAYCHECK- AMOUNT Data stores EMPLOYEES shown again because accessed again. Need the entire record to update the file. Just like COBOL. Show a single read to a file within a diagram, then pass the data to everywhere it is needed. PAYCHECK-AMOUNT VALID-HOURS-WORKED PAY-RATE 1.4 PRODUCE- EMPLOYEE- PAYCHECK EMPLOYEE-PAYCHECK EMPLOYEE- PAYCHECK- DETAIL PAYCHECK-AMOUNT PAYROLL-AUDIT-TRAIL 1.5 PRODUCE- REPORTING PAYROLL-VOUCHER GENERAL-LEDGER-ACCOUNT-NUMBER 55

56 Diagram 1 Look at data flows… 56 EMPLOYEES EMPLOYEE-RECORD
EMPLOYEE-HOURS-WORKED-TRANSACTION 1.3 UPDATE- EMPLOYEE- RECORD 1.1 EDIT-HOURS- WORKED- TRANSACTION 1.2 CALCULATE- EMPLOYEE- PAYCHECK- AMOUNT PAYCHECK-AMOUNT VALID-HOURS-WORKED PAY-RATE Look at data flows… 1.4 PRODUCE- EMPLOYEE- PAYCHECK EMPLOYEE-PAYCHECK EMPLOYEE- PAYCHECK- DETAIL PAYCHECK-AMOUNT PAYROLL-AUDIT-TRAIL 1.5 PRODUCE- REPORTING PAYROLL-VOUCHER GENERAL-LEDGER-ACCOUNT-NUMBER 56

57 Convergence, divergence (shown here) versus multiple copies.
Diagram 1 EMPLOYEES EMPLOYEE-RECORD Data flows Convergence, divergence (shown here) versus multiple copies. EMPLOYEE-HOURS-WORKED-TRANSACTION 1.3 UPDATE- EMPLOYEE- RECORD 1.1 EDIT-HOURS- WORKED- TRANSACTION 1.2 CALCULATE- EMPLOYEE- PAYCHECK- AMOUNT PAYCHECK-AMOUNT VALID-HOURS-WORKED PAY-RATE 1.4 PRODUCE- EMPLOYEE- PAYCHECK EMPLOYEE-PAYCHECK EMPLOYEE- PAYCHECK- DETAIL PAYCHECK-AMOUNT PAYROLL-AUDIT-TRAIL 1.5 PRODUCE- REPORTING PAYROLL-VOUCHER GENERAL-LEDGER-ACCOUNT-NUMBER 57

58 Avoid tramp data--data that is shuffled around unnecessarily.
Diagram 1 EMPLOYEES EMPLOYEE-RECORD EMPLOYEE-HOURS-WORKED-TRANSACTION 1.3 UPDATE- EMPLOYEE- RECORD 1.1 EDIT-HOURS- WORKED- TRANSACTION 1.2 CALCULATE- EMPLOYEE- PAYCHECK- AMOUNT Data flows Avoid tramp data--data that is shuffled around unnecessarily. Never send data through one bubble on its way to another. Data should never go anywhere that it isn’t actually used. Why not? PAYCHECK-AMOUNT VALID-HOURS-WORKED PAY-RATE 1.4 PRODUCE- EMPLOYEE- PAYCHECK EMPLOYEE-PAYCHECK EMPLOYEE- PAYCHECK- DETAIL PAYCHECK-AMOUNT PAYROLL-AUDIT-TRAIL 1.5 PRODUCE- REPORTING PAYROLL-VOUCHER GENERAL-LEDGER-ACCOUNT-NUMBER 58

59 Bad Example Diagram 1 Data flows
EMPLOYEES Bad Example Data flows Tramp data -- shuffling through bubble 1.4 unnecessarily. EMPLOYEE-RECORD EMPLOYEE-HOURS-WORKED-TRANSACTION 1.3 UPDATE- EMPLOYEE- RECORD 1.1 EDIT-HOURS- WORKED- TRANSACTION 1.2 CALCULATE- EMPLOYEE- PAYCHECK- AMOUNT PAYCHECK-AMOUNT VALID-HOURS-WORKED PAY-RATE EMPLOYEE- PAYCHECK- DETAIL 1.4 PRODUCE- EMPLOYEE- PAYCHECK EMPLOYEE-PAYCHECK Original PAYCHECK-AMOUNT EMPLOYEE- PAYCHECK-DETAIL PAYROLL-AUDIT-TRAIL 1.5 PRODUCE- REPORTING PAYROLL-VOUCHER GENERAL-LEDGER-ACCOUNT-NUMBER 59

60 Diagram 1 Check balancing... 60 EMPLOYEES EMPLOYEE-RECORD
EMPLOYEE-HOURS-WORKED-TRANSACTION 1.3 UPDATE- EMPLOYEE- RECORD 1.1 EDIT-HOURS- WORKED- TRANSACTION 1.2 CALCULATE- EMPLOYEE- PAYCHECK- AMOUNT PAYCHECK-AMOUNT VALID-HOURS-WORKED PAY-RATE Check balancing... 1.4 PRODUCE- EMPLOYEE- PAYCHECK EMPLOYEE-PAYCHECK EMPLOYEE- PAYCHECK- DETAIL PAYCHECK-AMOUNT PAYROLL-AUDIT-TRAIL 1.5 PRODUCE- REPORTING PAYROLL-VOUCHER GENERAL-LEDGER-ACCOUNT-NUMBER 60

61 Overview Diagram Diagram 1 61 EMPLOYEE-HOURS-WORKED-TRANSACTION
PAYROLL-AUDIT-TRAIL 1 PRODUCE- EMPLOYEE- PAYCHECK GENERAL-LEDGER-ACCOUNT-NUMBER PAYROLL-VOUCHER EMPLOYEE-PAYCHECK EMPLOYEES EMPLOYEE-MAINTENANCE-TRANSACTION Diagram 1 2 MAINTAIN- EMPLOYEE- RECORD EMPLOYEE-PAY-RATE-TRANSACTION EMPLOYEE-MAINTENANCE-AUDIT-TRAIL EMPLOYEES EMPLOYEE-RECORD EMPLOYEE-HOURS-WORKED-TRANSACTION 1.1 EDIT-HOURS- WORKED- TRANSACTION 1.2 CALCULATE- EMPLOYEE- PAYCHECK- AMOUNT 1.3 UPDATE- EMPLOYEE- RECORD VALID-HOURS-WORKED PAYCHECK-AMOUNT PAY-RATE 1.4 PRODUCE- EMPLOYEE- PAYCHECK EMPLOYEE-PAYCHECK EMPLOYEE- PAYCHECK- DETAIL PAYCHECK-AMOUNT PAYROLL-AUDIT-TRAIL 1.5 PRODUCE- REPORTING PAYROLL-VOUCHER GENERAL-LEDGER-ACCOUNT-NUMBER 61

62 Diagram 1 Data flows An edit transforms data, so the name must change to reflect that. Name by the last transformation.

63 Diagram 1.1 Child of bubble 1.1 on Diagram 1.

64 Diagram 1.1 64 EMPLOYEES EMPLOYEE-HOURS-WORKED-TRANSACTION
EMPLOYEE-RECORD PAY-RATE EMPLOYEE-NAME-AND-NUMBER 1.1.1 VERIFY- EMPLOYEE- NUMBER INVALID-EMPLOYEE-NUMBER REGULAR-HOURS-WORKED 1.1.2 EDIT- REGULAR- HOURS- WORKED VALID-REGULAR-HOURS-WORKED INVALID-REGULAR-HOURS-WORKED OVERTIME-HOURS-WORKED 1.1.3 EDIT- OVERTIME- HOURS- WORKED VALID-OVERTIME-HOURS-WORKED INVALID-OVERTIME-HOURS-WORKED 64

65 Diagram 1.1 Functional primitive
A process that is not further decomposed into a lower level diagram. It performs only a single task. Bubbles 1.1.2, 1.1.2, and are functional primitives. Choosing what should be a functional primitive is rather arbitrary and uses circular reasoning. How do you know when you have a functional primitive? When you stop partitioning. When do you stop partitioning? When you have a functional primitive.

66 Diagram 1.1 66 EMPLOYEES EMPLOYEE-HOURS-WORKED-TRANSACTION
EMPLOYEE-RECORD PAY-RATE EMPLOYEE-NAME-AND-NUMBER 1.1.1 VERIFY- EMPLOYEE- NUMBER INVALID-EMPLOYEE-NUMBER VALID-REGULAR-HOURS-WORKED 1.1.2 EDIT- REGULAR- HOURS- WORKED VALID-REGULAR-HOURS-WORKED INVALID-REGULAR-HOURS-WORKED VALID-OVERTIIME-HOURS-WORKED 1.1.3 EDIT- OVERTIME- HOURS- WORKED VALID-OVERTIME-HOURS-WORKED INVALID-OVERTIME-HOURS-WORKED 66

67 Diagram 1.1 Error stubs 67 EMPLOYEES EMPLOYEE-HOURS-WORKED-TRANSACTION
EMPLOYEE-RECORD PAY-RATE EMPLOYEE-NAME-AND-NUMBER 1.1.1 VERIFY- EMPLOYEE- NUMBER INVALID-EMPLOYEE-NUMBER REGULAR-HOURS-WORKED 1.1.2 EDIT- REGULAR- HOURS- WORKED VALID-REGULAR-HOURS-WORKED INVALID-REGULAR-HOURS-WORKED Error stubs OVERTIIME-HOURS-WORKED 1.1.3 EDIT- OVERTIME- HOURS- WORKED VALID-OVERTIME-HOURS-WORKED INVALID-OVERTIME-HOURS-WORKED 67

68 Diagram 1.1 Error stub--a note that an error condition must be handled, with no details on how to handle. Used only for trivial errors, errors that haven’t yet made it into a file so they don't need undoing.

69 Diagram 1.1 Error stubs shown only on functional primitives.
Don't want to clutter higher level diagrams with such trivial details. Name the error stub by the field in error. 3rd balancing exception, since they are shown on lower levels but not on the higher ones.

70 Diagram 1.1 Check balancing... 70 EMPLOYEES
EMPLOYEE-HOURS-WORKED-TRANSACTION EMPLOYEE-RECORD PAY-RATE EMPLOYEE-NAME-AND-NUMBER 1.1.1 VERIFY- EMPLOYEE- NUMBER INVALID-EMPLOYEE-NUMBER VALID-REGULAR-HOURS-WORKED 1.1.2 EDIT- REGULAR- HOURS- WORKED VALID-REGULAR-HOURS-WORKED INVALID-REGULAR-HOURS-WORKED VALID-OVERTIIME-HOURS-WORKED 1.1.3 EDIT- OVERTIME- HOURS- WORKED VALID-OVERTIME-HOURS-WORKED INVALID-OVERTIME-HOURS-WORKED 70

71 ? Diagram 1 Diagram 1.1 71 EMPLOYEES EMPLOYEE-RECORD
EMPLOYEE-HOURS-WORKED-TRANSACTION 1.1 EDIT-HOURS- WORKED- TRANSACTION 1.2 CALCULATE- EMPLOYEE- PAYCHECK- AMOUNT 1.3 UPDATE- EMPLOYEE- RECORD VALID-HOURS-WORKED PAYCHECK-AMOUNT PAY-RATE 1.4 PRODUCE- EMPLOYEE- PAYCHECK EMPLOYEE-PAYCHECK EMPLOYEE- PAYCHECK- DETAIL PAYCHECK-AMOUNT PAYROLL-AUDIT-TRAIL 1.5 PRODUCE- REPORTING Diagram 1.1 PAYROLL-VOUCHER GENERAL-LEDGER-ACCOUNT-NUMBER EMPLOYEES EMPLOYEE-HOURS-WORKED-TRANSACTION EMPLOYEE-RECORD 1.1.1 VERIFY- EMPLOYEE- NUMBER PAY-RATE EMPLOYEE-NAME-AND-NUMBER INVALID-EMPLOYEE-NUMBER VALID-REGULAR-HOURS-WORKED ? 1.1.2 EDIT- REGULAR- HOURS- WORKED VALID-REGULAR-HOURS-WORKED INVALID-REGULAR-HOURS-WORKED VALID-OVERTIIME-HOURS-WORKED 1.1.3 EDIT- OVERTIME- HOURS- WORKED VALID-OVERTIME-HOURS-WORKED INVALID-OVERTIME-HOURS-WORKED 71

72 Diagram 1.1 VALID-HOURS-WORKED doesn’t match...
Parallel decomposition--one arrow on parent may become several arrows on the child diagram.

73 Diagram 1.1 The group data flow is broken into its pieces or choices.
Example: PAYMENT-TRANSACTION is broken into its pieces of CUSTOMER-NUMBER and PAYMENT-AMOUNT, each going a different direction. Example: UPDATE-TRANSACTION is broken into its choices of ADD-TRANSACTION, ALTER-TRANSACTION, DELETE-TRANSACTION, each one going a different direction.

74 Diagram 1.1 The multiple arrows on the child are equivalent to the single data flow on the parent. Disadvantage--Makes the diagram harder to read. Any alternatives? Evaluate each situation and use only when necessary. 4th balancing exception.

75 Diagram 1.1 So here, VALID-HOURS-WORKED-TRANSACTION breaks down into its pieces of VALID-REGULAR-HOURS-WORKED and VALID-OVERTIME-HOURS-WORKED.

76 Diagram 1 Diagram 1.1 76 EMPLOYEES EMPLOYEE-RECORD
EMPLOYEE-HOURS-WORKED-TRANSACTION 1.1 EDIT-HOURS- WORKED- TRANSACTION 1.2 CALCULATE- EMPLOYEE- PAYCHECK- AMOUNT 1.3 UPDATE- EMPLOYEE- RECORD VALID-HOURS-WORKED PAYCHECK-AMOUNT PAY-RATE 1.4 PRODUCE- EMPLOYEE- PAYCHECK EMPLOYEE-PAYCHECK EMPLOYEE- PAYCHECK- DETAIL PAYCHECK-AMOUNT PAYROLL-AUDIT-TRAIL 1.5 MAINTAIN- EMPLOYEE- RECORD PAYROLL-VOUCHER GENERAL-LEDGER-ACCOUNT-NUMBER Diagram 1.1 EMPLOYEES EMPLOYEE-HOURS-WORKED-TRANSACTION EMPLOYEE-RECORD 1.1.1 VERIFY- EMPLOYEE- NUMBER PAY-RATE EMPLOYEE-NAME-AND-NUMBER INVALID-EMPLOYEE-NUMBER VALID-REGULAR-HOURS-WORKED 1.1.2 EDIT- REGULAR- HOURS- WORKED VALID-REGULAR-HOURS-WORKED INVALID-REGULAR-HOURS-WORKED VALID-OVERTIIME-HOURS-WORKED 1.1.3 EDIT- OVERTIME- HOURS- WORKED VALID-OVERTIME-HOURS-WORKED INVALID-OVERTIME-HOURS-WORKED 76

77 Summary of Balancing Exceptions
Multiple copies of same item. Data stores not shown on higher levels. Error stubs. Parallel decomposition. Note: Convergence and divergence are not balancing exceptions, because they are internal to the diagram.

78 Data Conservation Data can't be created from scratch.
Data that goes into a bubble should be used. A “black hole” A “miracle” Data can't be created from scratch. Exception: current date and time.

79 Remaining Diagrams...

80 Always need a FORMAT when writing to files.
Diagram 1.3 EMPLOYEES YEAR-TO-DATE-TOTAL 1.3.1 CALCULATE- YEAR-TO- DATE- TOTAL Always need a FORMAT when writing to files. PAYCHECK-AMOUNT NEW-YEAR-TO-DATE-TOTAL 1.3.2 FORMAT- EMPLOYEE- RECORD EMPLOYEE-RECORD 80

81 Always need a FORMAT and a WRITE when writing to a printer.
Diagram 1.4 Secondary alias for EMPLOYEE-PAYCHECK EMPLOYEE-PAYCHECK-DETAIL FORMATTED- EMPLOYEE- PAYCHECK 1.4.1 FORMAT- EMPLOYEE- PAYCHECK 1.4.2 WRITE- EMPLOYEE- PAYCHECK EMPLOYEE-PAYCHECK PAYCHECK-AMOUNT Always need a FORMAT and a WRITE when writing to a printer. 81

82 Diagram 1.4 Avoid diagrams with only two bubbles.
Haven’t really partitioned much. Makes set of DFDs bulkier and harder to read. How would we avoid here?

83 Diagram 1.4 83 EMPLOYEE-PAYCHECK-DETAIL FORMATTED- EMPLOYEE- PAYCHECK
1.4.1 FORMAT- EMPLOYEE- PAYCHECK 1.4.2 WRITE- EMPLOYEE- PAYCHECK EMPLOYEE-PAYCHECK PAYCHECK-AMOUNT 83

84 Diagram 1 84 EMPLOYEES EMPLOYEE-RECORD
EMPLOYEE-HOURS-WORKED-TRANSACTION 1.3 UPDATE- EMPLOYEE- RECORD 1.1 EDIT-HOURS- WORKED- TRANSACTION 1.2 CALCULATE- EMPLOYEE- PAYCHECK- AMOUNT PAYCHECK-AMOUNT VALID-HOURS-WORKED PAY-RATE 1.4 FORMAT- EMPLOYEE- PAYCHECK 1.6 WRITE- 1.4 PRODUCE- EMPLOYEE- PAYCHECK 1.4 PRODUCE- EMPLOYEE- PAYCHECK EMPLOYEE-PAYCHECK EMPLOYEE- PAYCHECK- DETAIL PAYCHECK-AMOUNT PAYROLL-AUDIT-TRAIL 1.5 PRODUCE- REPORTING PAYROLL-VOUCHER GENERAL-LEDGER-ACCOUNT-NUMBER 84

85 Diagram 1.5 85 EMPLOYEE-PAYCHECK-DETAIL 1.5.1 FORMAT- PAYROLL- AUDIT-
TRAIL 1.5.2 WRITE- PAYROLL- AUDIT- TRAIL FORMATTED- PAYROLL-AUDIT-TRAIL PAYROLL-AUDIT-TRAIL PAYCHECK-AMOUNT 1.5.3 TOTAL- PAYCHECK- AMOUNTS EMPLOYEE-PAYCHECKS-TOTAL FORMATTED- PAYROLL- VOUCHER 1.5.5 FORMAT- PAYROLL- VOUCHER 1.5.6 WRITE- PAYROLL- VOUCHER PAYROLL-VOUCHER VALID-GENERAL-LEDGER-ACCOUNT-NUMBER 1.5.4 EDIT- GENERAL- LEDGER- ACCOUNT- NUMBER GENERAL-LEDGER-ACCOUNT-NUMBER 85 INVALID-GENERAL-LEDGER-ACOUNT-NUMBER

86 would create crossed lines.
Trying to diverge on EMPLOYEE-RECORD would create crossed lines. Diagram 2 EMPLOYEES EMPLOYEE-MAINTENANCE-TRANSACTION 2.1 EDIT- MAINTENANCE- TRANSACTION 2.2 FORMAT- EMPLOYEE- RECORD EMPLOYEE-RECORD EMPLOYEE-PAY-RATE-TRANSACTION EMPLOYEE-RECORD VALID-EMPLOYEE-MAINTENANCE-TRANSACTION 2.3 FORMAT- EMPLOYEE- MAINTENANCE- AUDIT- TRAIL FORMATTED-EMPLOYEE-MAINTENANCE- AUDIT-TRAIL 2.4 WRITE EMPLOYEE- MAINTENANCE- AUDIT- TRAIL EMPLOYEE-MAINTENANCE-AUDIT-TRAIL 86

87 to lower-level diagrams.
EMPLOYEES EMPLOYEE-MAINTENANCE-TRANSACTION EMPLOYEE-RECORD 2.1.1 VERIFY- EMPLOYEE- NUMBER VALID-EMPLOYEE-NUMBER EMPLOYEE-PAY-RATE-TRANSACTION VALID-DELETE-TRANSACTION INVALID-EMPLOYEE-NUMBER CHANGED-EMPLOYEE-FIELD 2.1.2 EDIT- CHANGED- EMPLOYEE- FIELD VALID-CHANGED-EMPLOYEE-FIELD ADD-TRANSACTION-WITH-VALID-EMPLOYEE-NUMBER 2.1.3 EDIT-ALL- EMPLOYEE- FIELDS VALID-ADD-TRANSACTION These would break down to lower-level diagrams. 2.1.4 EDIT- EMPLOYEE- PAY-RATE PAY-RATE VALID-PAY-RATE 87 INVALID- PAY-RATE

88 How do we know when to stop exploding?
Partition to tiny. Each bubble documented by 1/2 page or less (usually). Each bubble performs a single, indivisible function.

89 Clues that we haven't partitioned far enough
A process difficult to name. A single process has many inputs and/or many outputs.

90 Creating a DFD Identify terminators and their data flows, and use them to create a Context Diagram. Repeat until system completely partitioned to functional primitives: Do first draft of a single diagram, with processes and data flows. Do several more drafts of the diagram. Draw last version neatly.

91 Creating a DFD Redraw all diagrams for clarity, incorporating any changes. Walk through the diagrams with the project team. Return to prior steps if problems are encountered. Walk through with the users. Return to prior steps if problems are encountered.

92 Miscellaneous Show data movement, not physical movement of goods.
Use a CASE tool, a graphics package, or, if hand-drawn, use pencil, not ink.

93 Miscellaneous Minimize crossed lines. When necessary, show as follows:
Don't connect data flows to right side of a data store: EMPLOYEES

94 Miscellaneous Always write horizontally:
DATA-FLOW-2 DATA-FLOW-1 DATA-FLOW-3 Always write horizontally: Two copies on the diagram EMPLOYEES Indicate multiple copies of a data store by placing extra lines in the symbol:

95 Editing Patterns Different ways to edit potentially dirty data from the outside world...

96 Editing Patterns 96 EDIT- CUSTOMER- NUMBER NEW-CUSTOMER CUSTOMER-NAME
INVALID-CUSTOMER-NUMBER EDIT- CUSTOMER- NAME INVALID-CUSTOMER-NAME CUSTOMER-ADDRESS EDIT- CUSTOMER- ADDRESS INVALID-CUSTOMER-ADDRESS CUSTOMER-PHONE EDIT- CUSTOMER- PHONE VALID-NEW-CUSTOMER INVALID-CUSTOMER-PHONE 96

97 Editing Patterns 97 EDIT- NEW-CUSTOMER CUSTOMER- NUMBER NEW-CUSTOMER
INVALID-CUSTOMER-NUMBER EDIT- CUSTOMER- NAME INVALID-CUSTOMER-NAME NEW-CUSTOMER EDIT- CUSTOMER- ADDRESS NEW-CUSTOMER INVALID-CUSTOMER-ADDRESS EDIT- CUSTOMER- PHONE VALID-NEW-CUSTOMER INVALID-CUSTOMER-PHONE 97

98 Editing Patterns Acceptable editing pattern:
Showing upper level bubble... EDIT- NEW- CUSTOMER NEW-CUSTOMER VALID-NEW-CUSTOMER 98

99 Editing Patterns Parallel decomposition: Acceptable editing pattern.
NEW-CUSTOMER-NUMBER EDIT- CUSTOMER- NUMBER VALID-CUSTOMER-NUMBER INVALID-CUSTOMER-NUMBER EDIT- CUSTOMER- NAME NEW-CUSTOMER-NAME VALID-CUSTOMER-NAME INVALID-CUSTOMER-NAME EDIT- CUSTOMER- ADDRESS NEW-CUSTOMER-ADDRESS VALID-CUSTOMER-ADDRESS INVALID-CUSTOMER-ADDRESS EDIT- CUSTOMER- PHONE NEW-CUSTOMER-PHONE VALID-CUSTOMER-PHONE INVALID-CUSTOMER-PHONE 99

100 Parallel decomposition
Editing Patterns Some tramp data. Acceptable for first bubble only. EDIT- CUSTOMER- NUMBER VALID-CUSTOMER-NUMBER NEW-CUSTOMER Parallel decomposition INVALID-CUSTOMER-NUMBER VALID- CUSTOMER-NAME EDIT- CUSTOMER- NAME INVALID-CUSTOMER-NAME NEW-CUSTOMER-NAME VALID- CUSTOMER-ADDRESS EDIT- CUSTOMER- ADDRESS INVALID-CUSTOMER-ADDRESS NEW-CUSTOMER-ADDRESS EDIT- CUSTOMER- PHONE INVALID-CUSTOMER-PHONE NEW-CUSTOMER-PHONE VALID-CUSTOMER-PHONE 100100

101 Possible Signs of Errors
The diagram is entwined, choked with data flows. Some place cries out for a flag. Flows or processes don't lend themselves to good names. There is a wide discrepancy in leveling.

102 Possible Signs of Errors
The diagram shows: data composition, access methods to data (data dictionary). decisions, loops, insides of bubbles (process descriptions). The diagram makes you uneasy.

103 Analysis Model The first technical representation of a system.
Uses a combination of text and diagrams to represent software requirements (data, function, and behaviour) in an understandable way. Helps make it easier to uncover requirement inconsistencies and omissions. Two types are commonly used: structured analysis and object-oriented analysis. * SEPA 6th ed, Roger S. Pressman

104 Analysis Model Guidelines
Analysis products must be highly maintainable, especially the software requirements specification. Problems of size must be dealt with using an effective method of partitioning. Graphics should be used whenever possible. Differentiate between the logical (essential) and physical (implementation) considerations. Find something to help with requirements partitioning and document the partitioning before specification. Devise a way to track and evaluate user interfaces. Devise tools that describe logic and policy better than narrative text. * SEPA 6th ed, Roger S. Pressman

105 Analysis Model Objectives
Describe what the customer requires. Establish a basis for the creation of a software design. Devise a set of requirements that can be validated once the software is built. * SEPA 6th ed, Roger S. Pressman

106 Analysis Model Rules of Thumb
The model should focus on requirements that are visible within the problem or business domain and be written as a relatively high level of abstraction. Each element of the analysis model should add to the understanding of the requirements and provide insight into the information domain, function, and behaviour of the system. Delay consideration of infrastructure and non-functional models until design. Minimize coupling throughout the system. Be certain the analysis model provides value to all stakeholders. Keep the model as simple as possible. * SEPA 6th ed, Roger S. Pressman

107 Structured Analysis Model Elements
Data dictionary contains the descriptions of all data objects consumed or produced by the software Data flow diagram (DFD) provides an indication of how data are transformed as they move through the system; also depicts functions that transform the data flow (a function is represented in a DFD using a process specification or PSPEC) Entity relationship diagram (ERD) depicts relationships between data objects State diagram (SD) indicates how the system behaves as a consequence of external events, states are used to represent behaviour modes. Arcs are labelled with the events triggering the transitions from one state to another (control information is contained in control specification or CSPEC) * SEPA 6th ed, Roger S. Pressman

108 Functional Modeling and Information Flow (DFD)
Shows the relationships of external entities, process or transforms, data items, and data stores DFD's cannot show procedural detail (e.g., conditionals or loops) only the flow of data through the software Refinement from one DFD level to the next should follow approximately a 1:5 ratio (this ratio will reduce as the refinement proceeds) To model real-time systems, structured analysis notation must be available for time continuous data and event processing (e.g., Ward and Mellor or Hately and Pirbhai) * SEPA 6th ed, Roger S. Pressman

109 Data Modeling (ERD) Elements:
Data object - any person, organization, device, or software product that produces or consumes information Attributes - name a data object instance, describe its characteristics, or make reference to another data object Relationships - indicate the manner in which data objects are connected to one another * SEPA 6th ed, Roger S. Pressman

110 Behavioral Modeling (STD)
State transition diagrams represent the system states and events that trigger state transitions STD's indicate actions (e.g., process activation) taken as a consequence of a particular event A state is any observable mode of behaviour Hatley and Pirbhai control flow diagrams (CFD) and UML sequence diagrams can also be used for behavioural modelling * SEPA 6th ed, Roger S. Pressman

111 Behavioral Modeling Mendeskripsikan status sistem yang dapat muncul ketika perangkat lunak digunakan mendeskripsikan kelakuan sistem Tools: State Transition Diagram Control Specification Umumnya digunakan pada sistem waktu-nyata

112 State Transition Diagram
Contoh STD untuk mesin otomatis penjual minuman (tidak ada hubungannya dengan contoh sebelumnya): Minuman tersedia = 0 Terima koin baru Menunggu koin Menunggu masukan pilihan Mengeluarkan minuman Mengembalikan pembayaran inisialisasi Kembalikan pembayaran Permintaan pengembalian koin Pembayaran dikembalikan Terima permintaan Koin sah terdeteksi Keluarkan minuman Pembayaran mencukupi Minuman dikeluarkan

113 Data Dictionary (1) Menyimpan semua objek data yang dibutuhkan dan dihasilkan oleh PL objek data yang muncul pada: ERD DFD STD harus selengkap dan serinci mungkin contoh: Nama = nama_depan + nama_belakang

114 Data Dictionary (2) Berisi: Name Alias Where-used/how-used
nama utama yang muncul pada objek data, data store, atau external entity Alias nama lain yang digunakan Where-used/how-used daftar proses yang menggunakan data dan bagaimana menggunakannya Content description notasi untuk merepresentasikan isi data Supplementary information

115 Data Dictionary (3) Notasi: Jenis Notasi Arti
====================================== = Terdiri atas urutan + dan pilihan [ | ] atau pengulangan { } n Pengulangan sebanyak n kali ( ) Data optional * * pembatas komentar

116 Data Dictionary (4) Contoh:
nama mahasiswa = nama depan + nama belakang jenis kelamin = [perempuan | laki-laki] nomor telepon = (kode negara) + kode wilayah + nomor

117 Analysis OO Penjelasan Pemodelan OO; Pengenalan OOA+Diagram

118 OO Modeling Using UML Materi: Sejarah OOAD UML Diagram Literature
Fowler Jacobson

119 Evolution of OO Development Methods

120 History of OOAD leading to UML

121 History of UML

122 The Unified Modeling Language
Booch dan Rumbaugh mulai bekerja pada Unified Modeling Language (UML) pada tahun 1994 di bawah naungan Rational Inc. UML hanya menawarkan notasi Model, bukan metodologi bagaimana melakukan pemodelan. UML digunakan oleh metode pengembangan Objectory (Jacobson pada Rational).

123 The Unified Modeling Language
UML diusulkan oleh Rational Inc dan Hewlett-Packard sebagai standar untuk analisis dan desain berorientasi objek yang diadopsi oleh OMG (Object Management Group). Vendor memodifikasi alat mereka untuk membuat mereka konsisten dengan UML. UML was proposed by Rational Inc. and by Hewlett-Packard as a standard for object-oriented analysis and design and was adopted by the OMG. Vendors modify their CASE tools to make them consistent with UML.

124 UML Diagrams (1)

125 UML Diagrams (2)

126 Diagrams and Process

127 Diagrams and Process Use Case Diagrams Inception = Awal
Elaboration = Perluasan

128 Class & Package Diagrams
Diagrams and Process Class & Package Diagrams

129 Interaction Diagrams (Scenarios)
Diagrams and Process Interaction Diagrams (Scenarios)

130 Activity Diagrams (Workflow, Interclass Behavior)
Diagrams and Process Activity Diagrams (Workflow, Interclass Behavior)

131 State Transition Diagrams (Intraclass Behavior)
Diagrams and Process State Transition Diagrams (Intraclass Behavior)

132 Texts and Process Source Code

133 Diagrams and Process Deployment Diagrams

134 UML Use case Diagrams Menggambarkan perilaku fungsional sistem seperti yang terlihat oleh penggunanya. Class diagrams Menggambarkan struktur statis sistem ini: Classes, Associations Sequence diagrams Menggambarkan perilaku dinamis sebuah sistem: Actors, objects, messages Statechart diagrams Menggambarkan perilaku dinamis dari objek individu dari sistem: states, events, transitions Activity Diagrams Memodelkan perilaku dinamis sistem ini: activities, workflows (flowcharts) Let’s first look at the basic parts of UML. Use case Diagrams describe the functional behaviour of the system as seen by the user. Class diagrams describe the static structure of the system: Objects, Attributes, Associations Sequence diagrams describe the dynamic behaviour between actors and the system and between objects of the system Statechart diagrams describe the dynamic behaviour of an individual object (a finite state automaton) Activity Diagrams model the dynamic behaviour of a system, in particular its workflows (a flowchart)

135 Terimakasih 