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

Presentasi berjudul: "Analysis Modeling (1) TIM RPL Program Studi Teknik Informatika 1."— Transcript presentasi:

1

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

3 Kenapa Analisis Kebutuhan

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

5 Definisi Analisis Kebutuhan Focus on What not How

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

7 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

8 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

9 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

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

11 DFD DFD (Data Flow Diagram)

12 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

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

14 – 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. Symbols

15 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

16 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 Symbols

17 – 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! Symbols

18 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. Symbols DATA-FLOW-NAME * Data yang disalurkan ke modul tetapi modulnya tidak memerlukan

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

20 – 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? Symbols

21 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

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

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

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

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

26 EMPLOYEE GENERAL- LEDGER MANAGEMENT 0 PAYROLL EMPLOYEE-MAINTENANCE- TRANSACTION EMPLOYEE-HOURS-WORKED- TRANSACTION EMPLOYEE-PAYCHECK EMPLOYEE-PAY-RATE- TRANSACTION PAYROLL-AUDIT-TRAIL EMPLOYEE-MAINTENANCE- AUDIT-TRAIL PAYROLL-VOUCHER PAYROLL-AUDIT-TRAIL GENERAL-LEDGER- ACCOUNT-NUMBER 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. 25

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

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

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

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

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

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

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

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

35 2 MAINTAIN- EMPLOYEE- RECORD Overview Diagram 1 PRODUCE- EMPLOYEE- PAYCHECK EMPLOYEE-MAINTENANCE-TRANSACTION EMPLOYEE-PAY-RATE-TRANSACTION EMPLOYEE-HOURS-WORKED-TRANSACTION GENERAL-LEDGER-ACCOUNT-NUMBER PAYROLL-AUDIT-TRAIL PAYROLL-VOUCHER EMPLOYEE-PAYCHECK EMPLOYEE-MAINTENANCE-AUDIT-TRAIL 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. 34 EMPLOYEE

36 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. Overview Diagram

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

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

39 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. Overview Diagram

40 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. Overview Diagram

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

42 2 MAINTAIN- EMPLOYEE- RECORD Overview Diagram 1 PRODUCE- EMPLOYEE- PAYCHECK EMPLOYEE-MAINTENANCE- TRANSACTION EMPLOYEE-PAY-RATE-TRANSACTION EMPLOYEE-HOURS-WORKED- TRANSACTION GENERAL-LEDGER-ACCOUNT-NUMBER PAYROLL-AUDIT-TRAIL PAYROLL-VOUCHER EMPLOYEE-PAYCHECK EMPLOYEE-MAINTENANCE-AUDIT-TRAIL 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 PAYROLL-AUDIT- TRAIL GENERAL-LEDGER- ACCOUNT-NUMBER 41 EMPLOYEE Context Diagram

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

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

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

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

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

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

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

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

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

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

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

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

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

56 1.5 PRODUCE- REPORTING Diagram 1 1.4 PRODUCE- EMPLOYEE- PAYCHECK EMPLOYEES EMPLOYEE-HOURS- WORKED- TRANSACTION 1.3 UPDATE- EMPLOYEE- RECORD 1.1 EDIT-HOURS- WORKED- TRANSACTION 1.2 CALCULATE- EMPLOYEE- PAYCHECK- AMOUNT EMPLOYEE- RECORD PAYCHECK- AMOUNT VALID-HOURS- WORKED PAY-RATE PAYCHECK- AMOUNT EMPLOYEE- PAYCHECK- DETAIL EMPLOYEE-PAYCHECK PAYROLL-AUDIT-TRAIL PAYROLL-VOUCHER GENERAL-LEDGER-ACCOUNT-NUMBER 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. 55

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

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

59 1.5 PRODUCE- REPORTING Diagram 1 1.4 PRODUCE- EMPLOYEE- PAYCHECK EMPLOYEES EMPLOYEE-HOURS- WORKED- TRANSACTION 1.3 UPDATE- EMPLOYEE- RECORD 1.1 EDIT-HOURS- WORKED- TRANSACTION 1.2 CALCULATE- EMPLOYEE- PAYCHECK- AMOUNT EMPLOYEE- RECORD PAYCHECK- AMOUNT VALID-HOURS- WORKED PAY-RATE PAYCHECK- AMOUNT EMPLOYEE- PAYCHECK- DETAIL EMPLOYEE-PAYCHECK PAYROLL-AUDIT-TRAIL PAYROLL-VOUCHER GENERAL-LEDGER-ACCOUNT-NUMBER 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? 58

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

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

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

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

64 Diagram 1.1 Child of bubble 1.1 on Diagram 1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

80 Remaining Diagrams...

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

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

83 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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

104 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 6 th ed, Roger S. Pressman 103

105 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 6 th ed, Roger S. Pressman 104

106 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 6 th ed, Roger S. Pressman 105

107 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 6 th ed, Roger S. Pressman 106

108 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 6 th ed, Roger S. Pressman 107

109 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 6 th ed, Roger S. Pressman 108

110 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 6 th ed, Roger S. Pressman 109

111 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 6 th ed, Roger S. Pressman 110

112 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 111

113 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 Kembalikan pembayaran Terima koin baru Pembayaran dikembalikan Terima permintaan Koin sah terdeteksi Keluarkan minuman Pembayaran mencukupi Terima koin baru Minuman dikeluarkan 112

114 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 113

115 Data Dictionary (2) Berisi: –Name 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 114

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

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

118 Analysis OO 117 Penjelasan Pemodelan OO; Pengenalan OOA+Diagram

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

120 Evolution of OO Development Methods

121 History of OOAD leading to UML

122 History of UML

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

124 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).Object Management Group Vendor memodifikasi alat mereka untuk membuat mereka konsisten dengan UML.

125 UML Diagrams (1)

126 UML Diagrams (2)

127 Diagrams and Process

128 Use Case Diagrams

129 Diagrams and Process Class & Package Diagrams

130 Diagrams and Process Interaction Diagrams (Scenarios)

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

132 Diagrams and Process State Transition Diagrams (Intraclass Behavior)

133 Texts and Process Source Code

134 Diagrams and Process Deployment Diagrams

135 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)

136 135 Terimakasih