Dokumen tersebut membahas sistem analisis dan desain untuk sistem ATM. Terdapat penjelasan mengenai use case diagram, activity diagram, sequence diagram, dan class diagram untuk merepresentasikan sistem ATM. Diagram-diagram tersebut menggambarkan proses-proses yang terjadi dalam sistem ATM mulai dari memasukkan kartu, memasukkan PIN, mengecek saldo, mentransfer uang, hingga mengambil uang dan logout.
Dokumen ini membahas tentang analisis dan desain sistem untuk sistem ATM. Terdapat penjelasan mengenai diagram urutan dan diagram kelas yang menggambarkan interaksi antar objek dalam sistem ATM untuk beberapa kasus penggunaan seperti mengecek saldo, mentransfer uang, dan mengambil uang. Dokumen ini juga menampilkan contoh desain antarmuka pengguna untuk sistem ATM menggunakan perangkat lunak Netbeans.
Dokumen ini membahas tentang pemodelan proses bisnis dengan diagram aktivitas dan menggunakan sistem ATM sebagai contoh studi kasus. Diagram aktivitas digunakan untuk memvisualisasikan aliran kerja dalam suatu proses bisnis yang melibatkan beberapa departemen. Contoh aktivitas yang dimodelkan meliputi memasukkan PIN, mengecek saldo, mentransfer uang, mengambil uang, dan logout.
Tiga kalimat ringkasan dokumen tersebut adalah:
Dokumen tersebut membahas tentang pemodelan fungsional dengan menggunakan diagram kasus penggunaan dan diagram aktivitas untuk menganalisis dan merancang sistem informasi berdasarkan persyaratan bisnis. Dokumen tersebut juga menjelaskan tahapan analisis dan perancangan sistem serta komponen-komponen penting dalam pemodelan fungsional seperti aktor, kasus penggunaan, dan diagram aktivitas.
Dokumen tersebut membahas teknik dokumentasi sistem informasi, termasuk diagram alir proses, flowchart sistem, dan diagram input-proses-output. Berbagai teknik tersebut digunakan untuk merekam dan menganalisis aliran informasi dalam sistem akuntansi perusahaan.
Dokumen ini membahas tentang analisis dan desain sistem untuk sistem ATM. Terdapat penjelasan mengenai diagram urutan dan diagram kelas yang menggambarkan interaksi antar objek dalam sistem ATM untuk beberapa kasus penggunaan seperti mengecek saldo, mentransfer uang, dan mengambil uang. Dokumen ini juga menampilkan contoh desain antarmuka pengguna untuk sistem ATM menggunakan perangkat lunak Netbeans.
Dokumen ini membahas tentang pemodelan proses bisnis dengan diagram aktivitas dan menggunakan sistem ATM sebagai contoh studi kasus. Diagram aktivitas digunakan untuk memvisualisasikan aliran kerja dalam suatu proses bisnis yang melibatkan beberapa departemen. Contoh aktivitas yang dimodelkan meliputi memasukkan PIN, mengecek saldo, mentransfer uang, mengambil uang, dan logout.
Tiga kalimat ringkasan dokumen tersebut adalah:
Dokumen tersebut membahas tentang pemodelan fungsional dengan menggunakan diagram kasus penggunaan dan diagram aktivitas untuk menganalisis dan merancang sistem informasi berdasarkan persyaratan bisnis. Dokumen tersebut juga menjelaskan tahapan analisis dan perancangan sistem serta komponen-komponen penting dalam pemodelan fungsional seperti aktor, kasus penggunaan, dan diagram aktivitas.
Dokumen tersebut membahas teknik dokumentasi sistem informasi, termasuk diagram alir proses, flowchart sistem, dan diagram input-proses-output. Berbagai teknik tersebut digunakan untuk merekam dan menganalisis aliran informasi dalam sistem akuntansi perusahaan.
Diagram ini menggambarkan fungsionalitas yang diharapkan dari sistem berdasarkan sudut pandang pengguna, hubungan antara pengguna dan proses sistem, serta proses-proses sistem itu sendiri. Diagram ini terdiri atas use case, aktor, dan hubungan antara keduanya.
Dokumen tersebut memberikan penjelasan tentang:
1. Konsep dasar Data Flow Diagram (DFD) dan simbol-simbol yang digunakan dalam DFD.
2. Contoh proses bisnis sistem penggajian dan representasinya dalam berbagai tingkatan DFD.
3. Konsep Entity Relationship Diagram (ERD) dan langkah pembuatannya.
4. Beberapa teknik dokumentasi sistem lainnya seperti Hierarchy Input Proses Output (HIPO) dan pseudocode.
Ringkasan dokumen tersebut adalah: (1) dokumen tersebut membahas perlunya pengembangan sistem informasi dan prinsip-prinsipnya, (2) tahapan sistem development life cycle meliputi planning, analysis, design, dan implementation, (3) tahap analysis meliputi scope definition, problem analysis, requirement analysis, logical design, dan pemilihan sistem.
Simulasi sistem industri terdiri dari pengenalan simulasi, definisi simulasi, contoh simulasi pada bagian teller bank, dan tahapan proses simulasi. Simulasi digunakan untuk memodelkan sistem nyata, melakukan eksperimen dengan model, dan memprediksi perilaku sistem melalui simulasi komputer. Contoh simulasi pada teller bank melibatkan proses pelanggan antre dan dilayani untuk menentukan persentase waktu teller kosong.
1. Pendekatan sistem dan siklus hidup pengembangan sistem (SDLC) merupakan metodologi untuk memecahkan masalah sistem.
2. Diagram arus data dan kasus penggunaannya merupakan alat untuk memodelkan proses dan data dalam suatu sistem.
3. Manajemen proyek pengembangan sistem dikelola secara hierarki dari atas ke bawah oleh komite eksekutif dan steering committee.
Sistem analisis dan desain ATM menggunakan diagram kasus penggunaan untuk menggambarkan fungsi utama sistem seperti pengecekan saldo, pengiriman uang, dan pengambilan uang.
Buku Learning UML 2.0 membahas tentang activity diagram sebagai salah satu diagram yang digunakan untuk memodelkan proses bisnis. Activity diagram dapat digunakan untuk mevisualisasikan langkah-langkah dalam use case dan terdiri dari kumpulan aksi, subaktivitas, serta transisi yang dapat merepresentasikan aliran kerja dan percabangan dalam suatu proses.
Dokumen tersebut membahas tentang sistem pendukung keputusan (decision support system) yang mencakup 5 hal utama, yaitu: (1) pengambilan keputusan dan proses pemodelannya, (2) fase-fase dalam sistem pendukung keputusan, (3) jenis-jenis model yang digunakan, (4) keuntungan pemodelan, dan (5) faktor-faktor kesuksesan sistem pendukung keputusan.
The document discusses the importance of documentation in software testing. It notes that documentation is needed to record test implementation and results, and helps direct testing and reuse tests. There are different types of test documentation, including test plans, specifications, and analysis reports. Effective documentation provides benefits like training, communication, maintenance, and historical reference. Test documentation should be maintained throughout the software development life cycle.
1) The document discusses various metrics for measuring software productivity, quality, and testing at different stages of the software development process. It covers metrics for requirements, design, source code, testing, maintenance, and processes.
2) Key metrics discussed include defects per KLOC, function points, defect removal efficiency, and size-oriented vs function-oriented metrics. Metrics for object-oriented design, user interfaces, and project management are also summarized.
3) Collecting measures and developing metrics at each stage of development allows indicators to be obtained and improvements to be made to both the product and process. A variety of productivity, quality, and testing metrics can provide meaningful insights.
Diagram ini menggambarkan fungsionalitas yang diharapkan dari sistem berdasarkan sudut pandang pengguna, hubungan antara pengguna dan proses sistem, serta proses-proses sistem itu sendiri. Diagram ini terdiri atas use case, aktor, dan hubungan antara keduanya.
Dokumen tersebut memberikan penjelasan tentang:
1. Konsep dasar Data Flow Diagram (DFD) dan simbol-simbol yang digunakan dalam DFD.
2. Contoh proses bisnis sistem penggajian dan representasinya dalam berbagai tingkatan DFD.
3. Konsep Entity Relationship Diagram (ERD) dan langkah pembuatannya.
4. Beberapa teknik dokumentasi sistem lainnya seperti Hierarchy Input Proses Output (HIPO) dan pseudocode.
Ringkasan dokumen tersebut adalah: (1) dokumen tersebut membahas perlunya pengembangan sistem informasi dan prinsip-prinsipnya, (2) tahapan sistem development life cycle meliputi planning, analysis, design, dan implementation, (3) tahap analysis meliputi scope definition, problem analysis, requirement analysis, logical design, dan pemilihan sistem.
Simulasi sistem industri terdiri dari pengenalan simulasi, definisi simulasi, contoh simulasi pada bagian teller bank, dan tahapan proses simulasi. Simulasi digunakan untuk memodelkan sistem nyata, melakukan eksperimen dengan model, dan memprediksi perilaku sistem melalui simulasi komputer. Contoh simulasi pada teller bank melibatkan proses pelanggan antre dan dilayani untuk menentukan persentase waktu teller kosong.
1. Pendekatan sistem dan siklus hidup pengembangan sistem (SDLC) merupakan metodologi untuk memecahkan masalah sistem.
2. Diagram arus data dan kasus penggunaannya merupakan alat untuk memodelkan proses dan data dalam suatu sistem.
3. Manajemen proyek pengembangan sistem dikelola secara hierarki dari atas ke bawah oleh komite eksekutif dan steering committee.
Sistem analisis dan desain ATM menggunakan diagram kasus penggunaan untuk menggambarkan fungsi utama sistem seperti pengecekan saldo, pengiriman uang, dan pengambilan uang.
Buku Learning UML 2.0 membahas tentang activity diagram sebagai salah satu diagram yang digunakan untuk memodelkan proses bisnis. Activity diagram dapat digunakan untuk mevisualisasikan langkah-langkah dalam use case dan terdiri dari kumpulan aksi, subaktivitas, serta transisi yang dapat merepresentasikan aliran kerja dan percabangan dalam suatu proses.
Dokumen tersebut membahas tentang sistem pendukung keputusan (decision support system) yang mencakup 5 hal utama, yaitu: (1) pengambilan keputusan dan proses pemodelannya, (2) fase-fase dalam sistem pendukung keputusan, (3) jenis-jenis model yang digunakan, (4) keuntungan pemodelan, dan (5) faktor-faktor kesuksesan sistem pendukung keputusan.
The document discusses the importance of documentation in software testing. It notes that documentation is needed to record test implementation and results, and helps direct testing and reuse tests. There are different types of test documentation, including test plans, specifications, and analysis reports. Effective documentation provides benefits like training, communication, maintenance, and historical reference. Test documentation should be maintained throughout the software development life cycle.
1) The document discusses various metrics for measuring software productivity, quality, and testing at different stages of the software development process. It covers metrics for requirements, design, source code, testing, maintenance, and processes.
2) Key metrics discussed include defects per KLOC, function points, defect removal efficiency, and size-oriented vs function-oriented metrics. Metrics for object-oriented design, user interfaces, and project management are also summarized.
3) Collecting measures and developing metrics at each stage of development allows indicators to be obtained and improvements to be made to both the product and process. A variety of productivity, quality, and testing metrics can provide meaningful insights.
The document discusses various debugging techniques. It describes the brute force method, which involves taking memory dumps and adding print statements to locate bugs. This generates a large amount of data but requires little thought. The cause elimination method deduces or induces potential causes and tests hypotheses to eliminate them one by one. Other methods include trial and error, backtracking code to find failures, and forward tracking to see when results first became wrong. Principles for locating errors include thinking carefully and getting a fresh perspective. Principles for repairing errors are to fix the underlying cause, check for new errors, and re-evaluate the design when making changes.
The document discusses debugging processes and techniques. It defines debugging as the process of finding, correcting and removing bugs from programs. There are three main types of errors: syntactic, semantic, and logic errors. The debugging process involves reproducing the problem reliably, finding the source of the error, fixing just that one error, testing the fix, and optionally looking for more errors. Key debugging techniques include inserting print statements, using a debugger, explaining the code to someone else, and fixing only one error at a time. The overall goal of debugging is to methodically match symptoms to causes to locate and correct errors in code.
This document discusses various types of software testing strategies including integration testing, continuous integration testing, and system testing. It provides details on techniques like top-down integration, bottom-up integration, smoke testing, regression testing, interface testing, and acceptance and installation testing. The objectives are to learn about integration testing, continuous integration testing, and system testing. Key aspects of different strategies like top-down vs bottom-up integration and categories of system test cases are compared. Determining when to stop testing is noted as one of the most difficult questions.
The document provides an overview of software testing strategies. It discusses that the main objective of software testing is to systematically find errors without taking much time. It emphasizes the importance of choosing the best testing strategy. It then covers various software testing strategies including unit testing, integration testing, validation testing, and system testing. Unit testing involves testing individual software components in isolation while integration testing focuses on testing the interaction between integrated components. The document contrasts the incremental and "big bang" approaches to integration testing and argues that the incremental approach is more effective.
The document discusses object-oriented testing strategies. It explains that in object-oriented testing, the component being tested is a class-object rather than a function. Unit testing focuses on testing each class's operations and attributes. Integration testing focuses on testing groups of collaborating classes. Validation testing is based on use case scenarios from the object-oriented analysis model. The document provides details on techniques for unit testing, integration testing, and validation testing of object-oriented systems.
The document discusses various software testing techniques, including blackbox and whitebox testing. Blackbox testing focuses on functional requirements without seeing the internal structure and includes equivalence class testing, limit testing, robustness testing, and requirements testing. Whitebox testing uses internal program structure to derive test cases and focuses on all logical paths and decisions. It includes basis path testing and control structure testing such as conditional and loop testing. The document provides examples of applying these techniques.
This document discusses various software testing techniques classified into static, dynamic, and exhaustive categories. Static techniques like verification and static analysis do not require executing the program. Dynamic techniques execute the program and are divided into structure-oriented techniques like control flow testing and function-oriented techniques like function coverage and use case testing. Exhaustive techniques aim to cover all possible test cases. The document provides examples and explanations of different testing methods.
The document discusses software testing concepts including:
1. It defines key terms related to software defects such as errors, defects, failures, and faults.
2. It outlines the different phases of software testing from component/unit testing to acceptance testing and discusses principles of good testability.
3. It provides guidance on writing test plans and cases, including reviewing requirements, identifying test suites, and transforming use cases into test cases.
This document discusses methodology selection strategy for systems analysis and design. It explains that there is no single framework appropriate for every software project, and the methodology needs to be adapted to the specific team and product. It outlines important factors to consider like clarity of requirements, technology familiarity, system complexity, schedule constraints. The methodology should guide the team's process but allow flexibility. The success of the methodology is measured by timely delivery of quality product increments that satisfy stakeholders.
The document discusses software quality and testing. It defines software reliability as the probability of failure-free operation of a computer program in a given environment and time. Testing aims to find errors in programs to improve reliability, rather than show a program works correctly. The document outlines ISO quality standards for software development including ISO 9001, which provides a framework for quality processes and procedures. Organizations must comply with ISO 9001 requirements to achieve quality certification.
The document discusses software quality assurance and testing. It defines software quality as having two aspects - quality of design which includes requirements and specifications, and quality of conformance which focuses on implementation. Software Quality Assurance (SQA) includes quality management, effective engineering processes, formal techniques, testing strategies, documentation control, and measurement/reporting. SQA aims to ensure requirements quality, design quality, code quality, and effective quality control. Non-functional attributes like reliability, usability, and performance largely determine a software's subjective quality from a user's perspective.
The document describes an introduction to software testing presentation. It discusses the software development life cycle (SDLC) which includes planning, analysis, design, implementation, and maintenance phases. It then explains different software development methodologies like structured design, rapid application development, and agile development. Finally, it provides definitions and goals of software testing, and presents a model of the software testing process.
The document discusses use case diagrams for systems analysis and design. It provides examples of use case diagrams for an appointment system and an ATM system. Key elements of use case diagrams are described, including actors, use cases, relationships like generalization, include and extend, and the system boundary. The ATM system example demonstrates how a use case diagram can model the interactions between an actor (user) and the various functions of an ATM machine like checking balance, transferring money, withdrawing money and logging out.
Systems analysis and design techniques are discussed, including requirement gathering and business process analysis. Requirement gathering involves document analysis, interviews, questionnaires, and observation to understand user needs. Functional requirements define system functions while non-functional requirements address system qualities. Business process analysis assesses current processes and can involve automation, improvement, or reengineering. Barriers to effective requirement gathering include users finding additional needs after seeing a system ("yes but" syndrome), incomplete discovery of all needs ("undiscovered ruins" syndrome), and communication gaps between users and developers.
The document discusses a feasibility analysis for a proposed CD Selections Internet Order System project.
The technical feasibility is determined to be medium risk overall, as the application and technology are somewhat unfamiliar but compatible with existing systems. The economic feasibility analysis shows a 229% return on investment over 3 years with a break-even point of 1.7 years. The organizational feasibility is low risk as the project aligns with goals of increasing sales and becoming more Internet-savvy.
The document discusses different agile development methodologies including Extreme Programming (XP), Scrum, Lean Development, and Dynamic Systems Development Model (DSDM). It provides details on the key aspects of XP and Scrum. XP focuses on communication, simplicity, feedback, and courage. Scrum uses self-organized teams, sprints to develop functionality in iterations with feedback from customers. While XP deals with programming and Scrum with project organization, Lean Development focuses on principles for the entire development organization. Factors like requirements clarity, technology familiarity, complexity, reliability, schedules, and schedule visibility should be considered when selecting a methodology.
This document discusses systems analysis and design methodologies. It covers structured design methodologies like the waterfall method and parallel development. It also discusses rapid application development, agile development approaches like extreme programming and scrum, and compares their activities and artifacts. The structured design approaches like waterfall involve completing each phase before beginning the next, while agile methods are more adaptive. Waterfall has long timelines but minimizes changes, while parallel development addresses the time gap by breaking a project into parallel subprojects.
1. Systems Analysis
and Design
By : Ajeng Savitri P, M.Kom
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
5. System Analysis and Design with UML
1. System Analysis
1. Business Process Identification
• Use Case Diagram
2. Business Process Modeling
• Activity Diagram or Business Process Modeling Notation
(BPMN)
3. Business Process Realization
• Sequence Diagram (Buat untuk setiap use case dengan menggunakan
pola Boundary-Control-Entity)
5
6. Use Case Diagrams
• Summarized into a single picture
• All of the use cases for the part of the system being modeled
• Use case represents the discrete activities performed by the
user
• Use Case Diagram tells what the system will do
• Good for communicating with users
6
7. Syntax for an Use Case Diagram
• Actor
• person or system that derives benefit from and is
external to the subject
• Use Case
• Represents a major piece of system functionality
• Association Relationship
• Include Relationship
• Extend Relationship
• Generalization Relationship
<<extends>>
<<includes>>
7
8. Use Case
• A major piece of system functionality
• Can extend other Use Cases
• Placed inside system boundary
• Labeled with descriptive verb - noun phrase
Use Case
8
9. System Boundary
• Includes the name of the system inside or on top
• Represents the scope of the system
• Actors are outside the scope of the system
Boundary
9
10. Actor
• A person or another system that interacts with the
current system
• A role, not a specific user
• Provides input, receives output, or both
actor
Actor/Role
10
11. Association Relationship
• Links actor and the Use Case
• Shows two-way communication
• If one-way, arrows are used
• * is for "multiplicity of the Association"
* *
11
12. Extends Relationship
• Extends Use Case to include Optional behavior
• Arrow points from the extension Use Case to the
base Use Case
extend
extend Make
Appointment
Make Payment
Arrangement
12
13. Include Relationship
• Include one Use Case from within another
• Arrow points from base Use Case to the
included Use Case
include
include Create New
Patient
Make New
Patient Appointment
13
14. Generalization Relationship
• A specialized Use Case to a more generalized Use
Case
• Arrow points from specialized to general Use Case
Make
Appointment
Make Old
Appointment
14
20. BPM With Activity Diagrams
• A number of activities support a business process across
several departments
• Activity diagrams model the behavior in a business
process
20
23. Creating Activity Diagrams
1. Set the context or scope of the activity being modeled
2. Identify the activities and control/object flows
between activities
3. Identify any decisions made
4. Look for opportunities for parallelism
5. Draw the diagram
23
26. Sequence Diagrams
• Illustrate the objects that participate in a use case
• Show the messages that pass between objects for a
particular use-case over time
26
27. Sequence Diagram Syntax
AN ACTOR
AN OBJECT
A LIFELINE
A FOCUS OF CONTROL
A MESSAGE
OBJECT DESTRUCTION
anObject:aClass
aMessage()
x
27
28. Sequence Diagram
1. Susun Sequence Diagram untuk setiap Use Case yang
dibuat
2. Mulai dari menarik Actor yang ada di Use Case
Diagram, lanjutkan dengan membuat sequence detail
dari berjalannya Use Case
Catatan: Objek dari Lifeline di Sequence Diagram akan menjadi kandidat Class
28
29. Jenis Class
1. Boundary Class:
• Class yang berinteraksi dengan aktor langsung (user interface)
• Form, input, UI ini masuk di sini
2. Control Class:
• Class yang berhubungan dengan pemrosesan, penghitungan,
kalkulasi, komputasi, query, dst
3. Entity Class:
• Class yang berhubungan dengan data, penyimpanan data/file
29
43. Use Case Diagramuc UCD - Sistem ATM
Pengguna
Sistem ATM
Memasukkan Kartu Memasukkan PIN
Mengecek Saldo
Mentransfer Uang
Mengambil UangMelakukan Logout
«include»
43
44. Use Case Diagram (Alternatif)uc Sistem ATM
Sistem ATM
Pengguna
Memasukkan Kartu Memasukkan PIN
Memilih Transaksi
Melihat Saldo
Mengirim Uang
Mengambil Uang
Melakukan Logout
Admin
Mengganti Kotak
Deposit
«include»
«extend»
«extend»
«extend»
44
46. Activity Diagram: Memasukkan Kartu
act AD1 - Memasukkan Kartu
Mulai
Pengguna Sistem ATM
Menyiapkan Kartu
Memasukkan Kartu Memv alidasi Kartu
kartu valid?
Menampilkan MenuPIN
Mengeluarkan Kartu
Selesai
tidak
ya
46
47. Activity Diagram: Memasukkan PIN
act AD2 - Memasukkan PIN
Pengguna Sistem ATM
Mulai
Memasukkan PIN
Memv alidasi Account
pin valid?
Menampilkan MenuUtama
lebih dari 3x?
Memblokkir Kartu
Selesai
ya
tidak
tidak
ya
47
48. Activity Diagram: Mengecek Saldo
act AD3 - Mengecek Saldo
Pengguna Sistem ATM
Mulai
Memilih Mengecek Saldo
di Menu Utama
Memproses Pengecekan
Saldo
Menampilkan Saldo di
Menu Saldo
Selesai
48
49. Activity Diagram: Mentransfer Uang
act AD4 - Mentransfer Uang
Pengguna Sistem ATM
Mulai
Memilih Mentransfer Uang
di Menu Utama
Memasukkan Account
Tujuan
Memasukkan Jumlah
Uang yang dikirim
Menghitung Kecukupan
Saldo Pengirim
Memv alidasi Account
Tujuan
Account Tujuan Valid?
Saldo Cukup?
Mentransfer Uang
Selesai
tidak
ya
tidak
ya
49
50. Activity Diagram: Mengambil Uang
act AD5 - Mengambil Uang
Pengguna Sistem ATM
Mulai
Memilih Menu Mengambil
Uang di Menu Utama
Memasukkan Jumlah
Uang
Mengecek Ketercukupan
Saldo
Saldo Cukup?
Memproses Pengambilan
Uang
Mengeluarkan Uang di
Kotak Uang
Mengambil Uang di Kotak
Uang
Selesai
tidak
ya
50
51. Activity Diagram: Melakukan Logout
act AD6 - Melakukan Logout
Sistem ATMPengguna
Mulai
Memilih Keluar di Menu
Utama
Memproses Logout
Mengeluarkan Kuitansi
Mengeluarkan KartuMengambil Kuitansi
Mengambil Kartu
Selesai
51
53. Sequence Diagram: Memasukkan Kartu
sd SD1 - Memasukkan Kartu
Pengguna
(from 1 Use Case Diagram)
KotakKartu ProsesValidasiKartu MenuPIN
alt kartu valid?
[ya]
[tidak]
memasukanKartu()
validasiKartu()
tampilkan()
mengeluarkanKartu()
53
54. Sequence Diagram: Memasukkan PIN
sd SD2 - Memasukkan PIN
Pengguna
(from 1 Use Case Diagram)
MenuPIN ProsesValidasiAccount LoginAccount MenuUtama
alt PIN valid?
[ya]
[tidak]
alt lebih dari 3x?
[tidak]
[ya]
memasukkanPIN()
validasi(id, pin)
getIDLogin()
getPIN()
tampilkan()
tampilkan()
blokirAccount()
errorKartuDiblokir()
54
55. Sequence Diagram: Mengecek Saldo
sd SD3 - Mengecek Saldo
Pengguna
(from1 Use Case Diagram)
MenuUtama MenuMengecekSaldoProsesMengecekSaldo Account Balance Transaksi
memilihMengecekSaldo()
lihatSaldo(id)
getIDBalance()
getSaldo()
setTransaksi(tgl, jenis)
tampilkanHasil(saldo)
55