Analysis Modeling. TIM RPL Program Studi Teknik Informatika

Analysis Modeling

TIM RPL Program Studi Teknik Informatika

1

Kenapa Analisis Kebutuhan

Definisi Analisis Kebutuhan

“Penguraian kebutuhan-kebutuhan yang utuh ke dalam bagianbagian komponennya dengan maksud untuk mengidetifikasikan dan mengevaluasi permasalahan dan hambatan sehingga dapat

diusulkan perbaikan.”

Definisi Analisis Kebutuhan

Focus on What not How

Langkah-Langkah Analisis Kebutuhan

1. Identifikasi 2. Pemahaman 3. Pemodelan (Core of Analysis) 4. Pembuatan laporan


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


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

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

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-prose yang memanipulasi objek data dimodelkan dengan

cara

menggambarkan

bagaimana

proses-proses

tersebut mengubah data sebagai aliran objek melalui sistem

DFD

DFD (Data Flow Diagram)

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

Terminator / External Entity – Orang atau organisasi yang terletak di luar sistem dan pencetus atau penerima data.

EMPLOYEE

– Source (pencetus data) or sink (penerima

data). – Sumber utama di sisi kiri dari DFD, selanjutnya di sisi kanan. – Nama terminator dalam kotak. 

Key - outside the area of our concern and control.

Data Store • Data store (file)

EMPLOYEE

– Sama seperti data store di kamus data.

– Bisa berbentuk file computer, berkas kartu, lemari arsip, dll. – Perhatikan bahwa EMPLOYEE di sini menyimpan data yang berisi informasi karyawan, sedangkan EMPLOYEE (terminator) adalah orang yang sebenarnya.

Process • Process (bubble, transform) – Sebuah aktifitas, tugas, fungsi.

1 PRODUCEEMPLOYEEPAYCHECK

– Menunjukkan pekerjaan yang dilakukan terhadap data. • Transformasi data masuk ke data keluar. • Status perubahan (logical) atau isi, format, atau media (fisik).

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

Data Flow 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 ringkas dan punya arti.

Data Flow [2] – Panah menunjukkan arah pergerakan data. – Masuk dan keluar dari data store Write to data store

Read from data store

EMPLOYEE Akses ke data store (request atau key) tidak ditampilkan, hanya hasilnya saja.

Data Flow [3] – 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-NEXTCUST. • Hindari penamaan yang samar-samar seperti -INFO, -DATA.

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

Context Diagram PAYROLL-AUDIT-TRAIL EMPLOYEE-MAINTENANCEAUDIT-TRAIL MANAGEMENT

EMPLOYEE-MAINTENANCETRANSACTION EMPLOYEE-HOURS-WORKEDTRANSACTION 0

EMPLOYEE

EMPLOYEE-PAY-RATETRANSACTION

PAYROLL EMPLOYEE-PAYCHECK

GENERAL-LEDGERACCOUNT-NUMBER GENERALLEDGER PAYROLL-VOUCHER PAYROLL-AUDIT-TRAIL

Clearly labeled “Context Diagram”

Context Diagram Terminator

Process bubble PAYROLL-AUDIT-TRAIL Terminator

EMPLOYEE-MAINTENANCEAUDIT-TRAIL MANAGEMENT


EMPLOYEE-PAY-RATEEMPLOYEE-PAY-RATE TRANSACTION

Terminator

EMPLOYEE PAYROLL EMPLOYEE-PAYCHECK

GENERAL-LEDGERACCOUNT-NUMBER

Data flows...

GENERALLEDGER PAYROLL-VOUCHER PAYROLL-AUDIT-TRAIL

20

Context Diagram • Process bubbles • Di sini, hanya satu, yang mewakili seluruh sistem. • Bernomor 0, atau nomor dihilangkan. PAYROLL-AUDIT-TRAIL • Ada sesuatu yang salah di sini? EMPLOYEE-MAINTENANCEAUDIT-TRAIL MANAGEMENT



EMPLOYEE PAYROLL EMPLOYEE-PAYCHECK


GENERALLEDGER PAYROLL-VOUCHER

PAYROLL-AUDIT-TRAIL

21

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 primePAYROLL-AUDIT-TRAIL sinks on the EMPLOYEE-MAINTENANCEright. AUDIT-TRAIL • Can also show above and below. EMPLOYEE-MAINTENANCE• Shown here, then never again on lower levels. TRANSACTION EMPLOYEE-HOURS-WORKEDTRANSACTION

MANAGEMENT

EMPLOYEE-PAY-RATETRANSACTION 0 PAYROLL

EMPLOYEE EMPLOYEE-PAYCHECK



PAYROLL-AUDIT-TRAIL

22

Context Diagram

• Data stores PAYROLL-AUDIT-TRAIL • Bersifat internal untuk sistem, tidak ada EMPLOYEE-MAINTENANCElevel untuk ini AUDIT-TRAIL MANAGEMENT

EMPLOYEE-MAINTENANCETRANSACTION EMPLOYEE-HOURS-WORKEDTRANSACTION





PAYROLL-AUDIT-TRAIL

23

Context Diagram

• Data flows PAYROLL-AUDIT-TRAIL • Panjang, deskriptif, nama tunggal. EMPLOYEE-MAINTENANCE• Sebuah "paket" dari data yang terkait AUDIT-TRAIL secara logis. EMPLOYEE-MAINTENANCETRANSACTION EMPLOYEE-HOURS-WORKEDTRANSACTION

MANAGEMENT





PAYROLL-AUDIT-TRAIL

24

Context Diagram • Adakah yang salah dengan ini? PAYROLL-AUDIT-TRAIL EMPLOYEE-MAINTENANCEAUDIT-TRAIL MANAGEMENT






PAYROLL-AUDIT-TRAIL

25

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.

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.

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

Overview / Level 1 Diagram

PAYROLL-AUDIT-TRAIL

EMPLOYEE-HOURS-WORKED-TRANSACTION GENERAL-LEDGER-ACCOUNT-NUMBER


PAYROLL-VOUCHER EMPLOYEE-PAYCHECK

EMPLOYEE

EMPLOYEE-MAINTENANCE-TRANSACTION EMPLOYEE-PAY-RATE-TRANSACTION

2 MAINTAINEMPLOYEERECORD

EMPLOYEE-MAINTENANCE-AUDIT-TRAIL

30

Overview Diagram

PAYROLL-AUDIT-TRAIL




EMPLOYEE

• Process bubbles • Here, two major functions (bubbles). EMPLOYEE-MAINTENANCE-TRANSACTION • May have up 2 to seven bubbles on a diagram. EMPLOYEE-MAINTENANCE-AUDIT-TRAIL MAINTAIN• What about 1 bubble? EMPLOYEE-PAY-RATE-TRANSACTION EMPLOYEE• NumberedRECORD 1, 2, 3, etc. • Names have an active verb & object clause. • Avoid vague verbs like PROCESS. 31

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.

Overview Diagram

PAYROLL-AUDIT-TRAIL



EMPLOYEE


• Terminators • Shown only on Context, so not here.




33

Overview Diagram

PAYROLL-AUDIT-TRAIL



Read EMPLOYEES

Write EMPLOYEE-MAINTENANCE-TRANSACTION EMPLOYEE-PAY-RATE-TRANSACTION



• Data flows • Unique, descriptive names, generally long. • No reiteration, flags, or decisions. • Show direction of data EMPLOYEE-MAINTENANCE-AUDIT-TRAIL flow into/out of data stores. 34

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.

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.

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

Context Diagram PAYROLL-AUDIT-TRAIL EMPLOYEEMAINTENANCE-AUDITTRAIL EMPLOYEE-MAINTENANCETRANSACTION EMPLOYEE-HOURS-WORKEDTRANSACTION EMPLOYEE

MANAGEMENT

EMPLOYEE-PAYRATE-TRANSACTION

PAYROLL EMPLOYEEPAYCHECK

GENERAL-LEDGERACCOUNT-NUMBER GENERALLEDGER PAYROLL-VOUCHER PAYROLL-AUDITTRAIL

Overview Diagram EMPLOYEE-HOURS-WORKEDTRANSACTION GENERAL-LEDGER-ACCOUNT-NUMBER


PAYROLL-AUDIT-TRAIL PAYROLL-VOUCHER

EMPLOYEE-PAYCHECK

EMPLOYEE

EMPLOYEE-MAINTENANCETRANSACTION EMPLOYEE-PAY-RATE-TRANSACTION



38

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.

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.

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.

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.

Summary of the Overview Diagram

• If we draw a big circle around the Overview Diagram, bisecting the inputs and outputs, then

collapse the circle...

Overview Diagram PAYROLL-AUDIT-TRAIL




EMPLOYEES




45

Context Diagram PAYROLL-AUDIT-TRAIL

EMPLOYEE-MAINTENANCEAUDIT-TRAIL MANAGEMENT





GENERALLEDGER PAYROLL-VOUCHER PAYROLL-AUDIT-TRAIL

46

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

Diagram 1 EMPLOYEES

EMPLOYEERECORD EMPLOYEE-HOURSWORKEDTRANSACTION 1.1 EDIT-HOURSWORKEDTRANSACTION

VALID-HOURSWORKED

1.2 CALCULATEEMPLOYEEPAYCHECKAMOUNT

PAYCHECKAMOUNT

1.3 UPDATEEMPLOYEERECORD

PAY-RATE

1.4 PRODUCEEMPLOYEEPAYCHECK EMPLOYEEPAYCHECKDETAIL

GENERAL-LEDGER-ACCOUNT-NUMBER

EMPLOYEE-PAYCHECK

PAYCHECKAMOUNT PAYROLL-AUDIT-TRAIL 1.5 PRODUCEREPORTING

PAYROLL-VOUCHER

48

Diagram 1

EMPLOYEES


VALID-HOURSWORKED


PAYCHECKAMOUNT


PAY-RATE

• Process bubbles • Numbering: each bubble number consists of the diagram number, a EMPLOYEEPAYCHECKdecimal, and a local DETAIL number. • Look at bubble GENERAL-LEDGER-ACCOUNT-NUMBER functions…

1.4 PRODUCEEMPLOYEEPAYCHECK

EMPLOYEE-PAYCHECK


PAYROLL-VOUCHER

49

Diagram 1

EMPLOYEES


VALID-HOURSWORKED


PAYCHECKAMOUNT


PAY-RATE



EMPLOYEE-PAYCHECK


PAYROLL-VOUCHER

50

Diagram 1

EMPLOYEES


VALID-HOURSWORKED


PAYCHECKAMOUNT


PAY-RATE

• Process bubbles • There can be multiple ways of partitioning. EMPLOYEEPAYCHECK• Example: Combine 1.4 DETAIL and 1.5 into one bubble on this level. GENERAL-LEDGER-ACCOUNT-NUMBER


EMPLOYEE-PAYCHECK


PAYROLL-VOUCHER

51

EMPLOYEES

Diagram 1


VALID-HOURSWORKED PAY-RATE

EMPLOYEEPAYCHECKDETAIL




• Data stores PAYCHECK• EMPLOYEES shown AMOUNT again because accessed again. • Need1.4the entireEMPLOYEE-PAYCHECK record to PRODUCEupdate the file. EMPLOYEEPAYCHECK • Just like COBOL. PAYCHECKAMOUNT • Show a single read to a PAYROLL-AUDIT-TRAIL file within a diagram, 1.5 PAYROLL-VOUCHER PRODUCEthen pass the data to REPORTING everywhere it is needed. 52

Diagram 1

EMPLOYEES


VALID-HOURSWORKED


PAYCHECKAMOUNT


PAY-RATE

Look at data flows…




EMPLOYEE-PAYCHECK


PAYROLL-VOUCHER

53

EMPLOYEES

Diagram 1


VALID-HOURSWORKED

• Data flows 1.2 • Convergence,1.3divergence CALCULATEUPDATEEMPLOYEE(shown here) versus multiple EMPLOYEEPAYCHECKRECORD PAYCHECKAMOUNT copies. AMOUNT

PAY-RATE



EMPLOYEE-PAYCHECK


PAYROLL-VOUCHER

54

EMPLOYEES

Diagram 1


VALID-HOURSWORKED PAY-RATE





• Data flows PAYCHECK• Avoid tramp data--data AMOUNT that is shuffled around unnecessarily. • Never through 1.4 send data EMPLOYEE-PAYCHECK PRODUCEone bubble on its way to EMPLOYEEPAYCHECK another. PAYCHECKAMOUNT• Data should never go PAYROLL-AUDIT-TRAIL anywhere that it isn’t 1.5 PRODUCEactually used. PAYROLL-VOUCHER REPORTING •Why not? 55

Diagram 1

Bad Example

EMPLOYEES

EMPLOYEERECORD

• Data flows • Tramp data -- shuffling through bubble 1.4 unnecessarily.

EMPLOYEE-HOURSWORKEDTRANSACTION 1.1 EDIT-HOURSWORKEDTRANSACTION

VALID-HOURSWORKED



PAYCHECKAMOUNT

PAY-RATE EMPLOYEEPAYCHECKDETAIL

Original

1.4 PRODUCEEMPLOYEEPAYCHECK PAYCHECKAMOUNT

EMPLOYEE-PAYCHECK

EMPLOYEEPAYCHECK-DETAIL PAYROLL-AUDIT-TRAIL


1.5 PRODUCEREPORTING

PAYROLL-VOUCHER

56

Diagram 1

EMPLOYEES


VALID-HOURSWORKED


PAYCHECKAMOUNT


PAY-RATE

Check balancing... 1.4 PRODUCEEMPLOYEEPAYCHECK EMPLOYEEPAYCHECKDETAIL


EMPLOYEE-PAYCHECK


PAYROLL-VOUCHER

57

Overview Diagram EMPLOYEE-HOURS-WORKEDTRANSACTION GENERAL-LEDGER-ACCOUNT-NUMBER


PAYROLL-AUDIT-TRAIL PAYROLL-VOUCHER EMPLOYEE-PAYCHECK

EMPLOYEES

EMPLOYEE-MAINTENANCETRANSACTION EMPLOYEE-PAY-RATE-TRANSACTION


Diagram 1

EMPLOYEE-MAINTENANCE-AUDIT-TRAIL EMPLOYEES EMPLOYEE-RECORD

EMPLOYEE-HOURSWORKED-TRANSACTION 1.1 EDIT-HOURSWORKEDTRANSACTION

1.2 CALCULATEEMPLOYEEPAYCHECKVALID-HOURS- AMOUNT WORKED PAY-RATE

EMPLOYEEPAYCHECKDETAIL GENERAL-LEDGER-ACCOUNT-NUMBER

1.3 UPDATEEMPLOYEERECORD PAYCHECKAMOUNT

1.4 PRODUCE- EMPLOYEE-PAYCHECK EMPLOYEEPAYCHECK PAYCHECKAMOUNT 1.5 PRODUCEREPORTING

PAYROLL-AUDIT-TRAIL PAYROLL-VOUCHER

58

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

Diagram 1.1 • Child of bubble 1.1 on Diagram 1.

Diagram 1.1

EMPLOYEES

EMPLOYEE-HOURSWORKEDTRANSACTION

INVALIDEMPLOYEENUMBER

EMPLOYEE-RECORD

1.1.1 VERIFYEMPLOYEENUMBER

PAY-RATE EMPLOYEE-NAME-AND-NUMBER

REGULARHOURS-WORKED

INVALIDREGULARHOURSWORKED OVERTIMEHOURS-WORKED INVALIDOVERTIMEHOURSWORKED

1.1.2 EDITREGULARHOURSWORKED

1.1.3 EDITOVERTIMEHOURSWORKED

VALID-REGULAR-HOURS-WORKED

VALID-OVERTIME-HOURS-WORKED

61

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.

Diagram 1.1

EMPLOYEES



EMPLOYEE-RECORD



VALIDREGULARHOURS-WORKED

INVALIDREGULARHOURSWORKED VALIDOVERTIIMEHOURS-WORKED

INVALIDOVERTIMEHOURSWORKED





63

EMPLOYEES

Diagram 1.1



EMPLOYEE-RECORD


Error stubs


REGULARHOURS-WORKED

INVALIDREGULARHOURSWORKED OVERTIIMEHOURS-WORKED






64

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.

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.

Diagram 1.1

EMPLOYEES

Check balancing... EMPLOYEE-HOURSWORKEDTRANSACTION


EMPLOYEE-RECORD



VALIDREGULARHOURS-WORKED

INVALIDREGULARHOURSWORKED VALIDOVERTIIMEHOURS-WORKED






67

Diagram 1

EMPLOYEES EMPLOYEE-RECORD

EMPLOYEE-HOURS1.1 WORKEDTRANSACTION EDIT-HOURS-

1.2 CALCULATEWORKEDEMPLOYEETRANSACTION PAYCHECKVALID-HOURS- AMOUNT WORKED


PAY-RATE



1.4 PRODUCE- EMPLOYEE-PAYCHECK EMPLOYEEPAYCHECK PAYCHECKAMOUNT 1.5 PRODUCEREPORTING

PAYROLL-AUDIT-TRAIL

Diagram 1.1

PAYROLL-VOUCHER

EMPLOYEES

EMPLOYEE-RECORD

EMPLOYEE-HOURSWORKED1.1.1 TRANSACTION VERIFYINVALIDEMPLOYEENUMBER

PAY-RATE

EMPLOYEENUMBER VALID-REGULARHOURS-WORKED

INVALIDREGULARHOURSWORKED VALID-OVERTIIMEHOURS-WORKED INVALIDOVERTIMEHOURS-WORKED

1.1.2 EDITREGULARHOURSWORKED 1.1.3 EDITOVERTIMEHOURSWORKED

EMPLOYEE-NAME-AND-NUMBER

?



68

Diagram 1.1

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

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,

TRANSACTION, each one going a different direction.

DELETE-

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.

Diagram 1.1 • So

here,

VALID-HOURS-WORKED-TRANSACTION

breaks down into its pieces of VALID-REGULARHOURS-WORKED WORKED.

and

VALID-OVERTIME-HOURS-

Diagram 1

EMPLOYEES EMPLOYEE-RECORD EMPLOYEEHOURSWORKEDTRANSACTION

1.1 EDIT-HOURSWORKEDTRANSACTION

1.2 CALCULATEEMPLOYEEPAYCHECKVALID-HOURSAMOUNT WORKED PAY-RATE




1.4 PRODUCE- EMPLOYEE-PAYCHECK EMPLOYEEPAYCHECK PAYCHECKAMOUNT

1.5 PAYROLL-AUDIT-TRAIL MAINTAINPAYROLL-VOUCHER EMPLOYEERECORD

Diagram 1.1

EMPLOYEES

EMPLOYEE-HOURSWORKED1.1.1 TRANSACTION VERIFYINVALIDEMPLOYEENUMBER

EMPLOYEE-RECORD PAY-RATE

EMPLOYEENUMBER VALID-REGULARHOURS-WORKED

INVALIDREGULARHOURSWORKED VALID-OVERTIIMEHOURS-WORKED INVALIDOVERTIMEHOURS-WORKED

1.1.2 EDITREGULARHOURSWORKED 1.1.3 EDITOVERTIMEHOURSWORKED

EMPLOYEE-NAME-AND-NUMBER



73

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

exceptions, because they are internal to the diagram.

balancing

Data Conservation • Data that goes into a bubble should be used.

A “black hole”

Data can't be created from scratch. 

Exception: current date and time.

A “miracle”

Diagram 1.3

EMPLOYEES

YEAR-TO-DATE-TOTAL

PAYCHECKAMOUNT

1.3.1 CALCULATEYEAR-TODATETOTAL NEW-YEAR-TODATE-TOTAL

EMPLOYEE-RECORD

1.3.2 FORMATEMPLOYEERECORD

Always need a FORMAT when writing to files.

77

Diagram 1.4 Secondary alias for EMPLOYEE-PAYCHECK

EMPLOYEE-PAYCHECKDETAIL PAYCHECK-AMOUNT

1.4.1 FORMATEMPLOYEEPAYCHECK

Always need a FORMAT and a WRITE when writing to a printer.

FORMATTEDEMPLOYEEPAYCHECK

1.4.2 WRITEEMPLOYEEPAYCHECK

EMPLOYEE-PAYCHECK

78

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?

Diagram 1.4

EMPLOYEE-PAYCHECKDETAIL PAYCHECK-AMOUNT

1.4.1 FORMATEMPLOYEEPAYCHECK

FORMATTEDEMPLOYEEPAYCHECK

1.4.2 WRITEEMPLOYEEPAYCHECK

EMPLOYEE-PAYCHECK

80

Diagram 1

EMPLOYEES


VALID-HOURSWORKED


PAYCHECKAMOUNT


PAY-RATE

1.4 PRODUCEFORMATEMPLOYEEPAYCHECK EMPLOYEEPAYCHECKDETAIL


1.6 WRITEEMPLOYEEEMPLOYEE-PAYCHECK PAYCHECK


PAYROLL-VOUCHER

81

Diagram 1.5 EMPLOYEE-PAYCHECKDETAIL

1.5.1 FORMATPAYROLLAUDITTRAIL

FORMATTEDPAYROLL-AUDIT-TRAIL

1.5.2 WRITEPAYROLLAUDITTRAIL

PAYROLL-AUDIT-TRAIL

PAYCHECK-AMOUNT

1.5.3 TOTALPAYCHECKAMOUNTS EMPLOYEEPAYCHECKS-TOTAL

1.5.5 FORMATPAYROLLVOUCHER

FORMATTEDPAYROLLVOUCHER

1.5.6 WRITEPAYROLLVOUCHER

PAYROLL-VOUCHER

VALID-GENERAL-LEDGERACCOUNT-NUMBER GENERAL-LEDGERACCOUNT-NUMBER

INVALID-GENERALLEDGER-ACOUNTNUMBER

1.5.4 EDITGENERALLEDGERACCOUNTNUMBER

82

Trying to diverge on EMPLOYEE-RECORD would create crossed lines.

EMPLOYEES

Diagram 2

EMPLOYEE-MAINTENANCETRANSACTION


2.1 EDITMAINTENANCETRANSACTION

EMPLOYEERECORD

EMPLOYEE-RECORD

2.2 FORMATEMPLOYEERECORD

VALID-EMPLOYEE-MAINTENANCETRANSACTION

2.3 FORMATEMPLOYEEMAINTENANCEAUDITTRAIL

FORMATTED-EMPLOYEEMAINTENANCEAUDIT-TRAIL

2.4 WRITE EMPLOYEEMAINTENANCEAUDITTRAIL

EMPLOYEEMAINTENANCEAUDIT-TRAIL

83

Diagram 2.1 EMPLOYEES

EMPLOYEE-MAINTENANCETRANSACTION

EMPLOYEE-PAY-RATETRANSACTION INVALIDEMPLOYEENUMBER

EMPLOYEE-RECORD


VALID-EMPLOYEE-NUMBER VALID-DELETE-TRANSACTION CHANGEDEMPLOYEEFIELD

ADD-TRANSACTION-WITHVALID-EMPLOYEE-NUMBER

2.1.2 EDITCHANGEDEMPLOYEEFIELD

2.1.3 EDIT-ALLEMPLOYEEFIELDS

VALID-CHANGED-EMPLOYEE-FIELD

VALID-ADD-TRANSACTION

These would break down to lower-level diagrams. PAY-RATE

INVALIDPAY-RATE

2.1.4 EDITEMPLOYEEPAY-RATE

VALID-PAY-RATE

84

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.

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

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.

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.

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

Miscellaneous • Minimize crossed lines. When necessary, show as follows:

Don't connect data flows to right side of a data store: EMPLOYEES

Miscellaneous • Always write horizontally:

DATAFLOW-1 DATAFLOW-2

Two copies on the diagram

Indicate multiple copies of a data store by placing extra lines in the symbol:

DATAFLOW-3

EMPLOYEES

EMPLOYEES

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

Editing Patterns NEW-CUSTOMER

EDITCUSTOMERNUMBER

INVALID-CUSTOMERNUMBER

INVALIDCUSTOMERNAME

CUSTOMERNAME EDITCUSTOMERNAME

CUSTOMER-ADDRESS

EDITCUSTOMERADDRESS INVALID-CUSTOMERADDRESS

CUSTOMERPHONE

INVALIDCUSTOMERPHONE

EDITCUSTOMERPHONE

VALID-NEW-CUSTOMER

93

Editing Patterns NEW-CUSTOMER

EDITCUSTOMERNUMBER

INVALID-CUSTOMERNUMBER

INVALIDCUSTOMERNAME

NEWCUSTOMER EDITCUSTOMERNAME NEW-CUSTOMER EDITCUSTOMERADDRESS INVALID-CUSTOMERADDRESS

NEWCUSTOMER

INVALIDCUSTOMER-PHONE

EDITCUSTOMERPHONE

VALID-NEW-CUSTOMER

94

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

EDITNEWCUSTOMER

VALID-NEW-CUSTOMER

95

Parallel decomposition: Parallel decomposition Acceptable editing pattern. NEW-CUSTOMERNUMBER

Editing Patterns VALID-CUSTOMER-NUMBER

EDITCUSTOMERNUMBER

INVALID-CUSTOMERNUMBER NEW-CUSTOMER-NAME INVALIDCUSTOMERNAME

EDITCUSTOMERNAME

VALID-CUSTOMER-NAME

EDITCUSTOMERADDRESS

NEW-CUSTOMER-ADDRESS

VALID-CUSTOMER-ADDRESS

INVALID-CUSTOMERADDRESS NEW-CUSTOMER-PHONE INVALIDCUSTOMERPHONE

EDITVALID-CUSTOMER-PHONE CUSTOMERPHONE

96

• Some tramp data. • Acceptable for first bubble only.

NEW-CUSTOMER

EDITCUSTOMERNUMBER

Editing Patterns

Parallel decomposition

VALID-CUSTOMER-NUMBER

INVALID-CUSTOMERNUMBER VALIDNEW-CUSTOMER-NAME INVALIDCUSTOMERNAME NEW-CUSTOMER-ADDRESS

EDITCUSTOMERNAME

VALID-

EDITCUSTOMERADDRESS INVALID-CUSTOMERADDRESS

NEW-CUSTOMER-PHONE INVALIDCUSTOMERPHONE

CUSTOMER-NAME

CUSTOMER-ADDRESS

EDITVALID-CUSTOMER-PHONE CUSTOMERPHONE

97

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

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.


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.


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.


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

Structured Analysis Model Elements • Data flow diagram (DFD)

– memberikan indikasi bagaimana data ditransformasikan ketika bergerak melalui sistem; juga menggambarkan fungsi yang mengubah aliran data (fungsi diwakili dalam DFD menggunakan process specification or PSPEC)

• Entity relationship diagram (ERD)

– menggambarkan hubungan antara objek data

• State diagram (SD)

– menunjukkan bagaimana sistem berperilaku sebagai konsekuensi dari peristiwa eksternal, status yang digunakan untuk mewakili mode perilaku. Busur diberi label dengan peristiwa memicu transisi dari satu status ke yang lain

• Data dictionary

– berisi deskripsi dari semua objek data yang dikonsumsi atau diproduksi oleh perangkat lunak * SEPA 6th ed, Roger S. Pressman105

Data Modeling (ERD) • Yang dimodelkan: data dan hubungannya • 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 106

Contoh ERD

107

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 108

State Transition Diagram • Contoh STD untuk mesin otomatis penjual minuman (tidak ada hubungannya dengan contoh sebelumnya): inisialisasi Pembayaran dikembalikan Terima koin baru

Terima koin baru

Menunggu koin Koin sah terdeteksi

Permintaan pengembalian koin

Terima permintaan

Minuman dikeluarkan Terima koin baru

Menunggu masukan pilihan Pembayaran mencukupi Keluarkan minuman

Kembalikan pembayaran

Mengembalikan pembayaran

Minuman tersedia = 0 Kembalikan pembayaran

Mengeluarkan minuman

109

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

110

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 111

Data Dictionary (3)

•

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

112

Data Dictionary (4)

• Contoh: – nama mahasiswa = nama depan + nama belakang

– jenis kelamin = [perempuan | laki-laki] – nomor telepon = (kode negara) + kode wilayah + nomor

113

Analysis OO

 Penjelasan Pemodelan OO;  Pengenalan OOA+Diagram

114

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

Evolution of OO Development Methods

History of OOAD leading to UML

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

(Jacobson pada Rational).

pengembangan

Objectory

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 Diagrams (2)

Diagrams and Process

Diagrams and Process Use Case Diagrams

Diagrams and Process Class & Package Diagrams

Diagrams and Process Interaction Diagrams (Scenarios)

Diagrams and Process Activity Diagrams (Workflow, Interclass Behavior)

Diagrams and Process State Transition Diagrams (Intraclass Behavior)

Texts and Process Source Code

Diagrams and Process Deployment Diagrams

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)

Studi Kasus Akan dibangun sebuah perangkat lunak untuk mendukung proses pendaftaran ulang mahasiswa secara online. Melalui aplikasi tersebut, mahasiswa dapat mengajukan usulan pengambilan matakuliah. Selanjutnya, dosen wali dapat menyetujui/menolak usulan pengambilan matakuliah. Usulan yang telah disetujui wali dapat langsung diproses oleh Petugas Administrasi untuk pencetakan KRS. KRS hanya bisa dicetak apabila status pembayaran SPP mahasiswa sudah beres. Informasi status pembayaran SPP diperoleh dari perangkat lunak lain yaitu SISKEU (Sistem Informasi Keuangan). Perangkat lunak ini juga akan berhubungan dengan perangkat lunak SIKAD (Sistem Informasi Akademik) untuk mendapatkan informasi tentang matakuliah yang ditawarkan pada semester tersebut, serta informasi transkrip nilai mahasiswa, agar dosen wali mendapatkan referensi untuk menyetujui/menolak usulan pengambilan matakuliah. 132

Tugas • Tugas dikumpulkan 17-04-2017 di meja Dosen. • Buatlah model analisis dari kasus berikut menggunakan diagram context dan overview diagram hingga 1 level berikutnya! • Bank Nusantara memiliki 3 jenis karyawan dengan tugas sebagai berikut : – Customer service (CS) : bertugas melayani nasabah dalam pembukuan rekening – Teller : bertugas melayani nasabah dalam melakukan transaksi penyetoran dan penarikan serta transfer. – Back office (BO) : bertugas memposting data semua transaksi yang terjadi pada hari yang bersangkutan. 133

Tugas [cont’] Prosedur Pelayanan Bank Nusantara • CS memberikan pelayanan kepada nasabah dengan memberikan penjelasan produk yang ditentukan oleh pihak manajemen bank. Jika nasabah berminat maka nasabah akan membuka rekening baru dan memberikan dokumen pendukung. Sebelum melakukan penginputan data nasabah, CS akan melihat apakah nasabah yang bersangkutan sebelumnya pernah membuka rekening di cabang lain atau tidak, bila belum maka CS harus melakukan penginputan seluruh informasi yang berkaitan dengan nasabah. • Teller menerima setoran awal dari nasabah serta menginput, memvalidasi transaksi dan mencetaknya ke dalam buku tabungan. • BO akan memposting semua data transaksi yang dibutuhkan pihak manajemen. Laporan yang dihasilkan berupa laporan harian, laporan per jenis transaksi, dan laporan nasabah baru. 134

Terimakasih 

135

Analysis Modeling. TIM RPL Program Studi Teknik Informatika

Recommend Documents