MỤC LỤC
Mô hình hoá phần mềm: UML cung cấp các khái niệm và biểu đồ để mô hình hoá các khía cạnh của phần mềm, bao gồm lớp, đối tượng, use case, sequence, state, activity, component, deployment, và interaction. Thiết kế phần mềm: UML cung cấp các công cụ để thiết kế các lớp, đối tượng, giao diện và các quan hệ giữa chúng, giúp tăng tính tái sử dụng và dễ bảo trì của phần mềm. Phát triển phần mềm: UML giúp xác định và quản lý các yêu cầu của phần mềm, phát triển các giải pháp thiết kế, thử nghiệm và triển khai phần mềm.
Tài liệu hóa phần mềm: UML giúp tạo ra tài liệu cho phần mềm như tài liệu thiết kế, tài liệu hướng dẫn sử dụng, tài liệu bảo trì, và các tài liệu khác liên quan đến phát triển và triển khai phần mềm. Giảm thiểu rủi ro và chi phí trong quá trình phát triển và triển khai phần mềm. Cung cấp một phương tiện chung để giao tiếp và hiểu nhau giữa các thành viên trong đội ngũ phát triển phần mềm.
Cung cấp một cách thức chuẩn để mô hình hoá phần mềm, giúp tăng tính chuẩn mực và tính nhất quán của các thiết kế và triển khai phần mềm. Tạo ra tài liệu cho phần mềm, giúp tăng tính đáng tin cậy và tính chuyên nghiệp của phần mềm.
Phù hợp với nhiều quy trình phát triển phần mềm: UML có thể được sử dụng trong nhiều quy trình phát triển phần mềm khác nhau, từ các quy trình phát triển phần mềm truyền thống đến các quy trình phát triển phần mềm nhẹ nhàng hơn như Agile. Mô hình hóa ở mức độ chung với quy trình có rẽ nhánh, lặp lại nhiều lần, có những sự kiện theo thời gian → khó biểu động phức tạp. Khụng thể hiện được rừ sự tớch hợp giải phỏp kỹ thuật vào quy trình nghiệp vụ.
Có thể sử dụng một số cộng cụ khác: BPMN, … để đạt được hiệu quả cao.
Khả năng tạo trường hợp sử dụng mở rộng và bao gồm: để mô hình hóa các trường hợp sử dụng phức tạp. Khả năng tạo sơ đồ trình tự: để mô tả luồng sự kiện trong một trường hợp sử dụng. Visual Paradigm là một công cụ mạnh mẽ và linh hoạt có thể được sử dụng để tạo biểu đồ trường hợp sử dụng cho nhiều loại hệ thống.
Nó dễ sử dụng và cung cấp nhiều tính năng để tạo các biểu đồ chuyên nghiệp và dễ hiểu. Biểu đồ này mô tả các trường hợp sử dụng cho một hệ thống bán hàng trực tuyến. Các diễn viên trong biểu đồ là khách hàng, nhân viên bán hàng và quản trị viên hệ thống.
Các trường hợp sử dụng là duyệt danh mục sản phẩm, đăng ký tài khoản, đặt hàng, thanh toỏn và theo dừi đơn hàng.
Người quản lý bán hàng: quyết định nhập hàng, giá bán, quản lý tồn kho, doanh thu, chính sách khuyến mãi. Người bỏn hàng: Tư vấn cho khỏch hàng, theo dừi đơn hàng, thu tiền, theo dừi chuyển hàng cho khỏch. Trước tiên, xem xét với Actor “Khách hàng tiềm năng” trên trang bkc.vn để xem họ sử dụng chức năng nào?.
Chức năng xem sản phẩm có 2 cách là chọn loại sản phẩm, nhà sản xuất để xem và gừ vào ụ tỡm kiếm. Chức năng mua hàng, thực chất là thêm vào giỏ hàng nên có thể xem là chức năng con của quản lý giỏ hàng. Chức năng “Thu tiền” thực tế là thanh toán trực tiếp tại quày cho từng đơn hàng và chức năng “Theo dừi chuyển hàng” được thực hiện trên từng đơn hàng nên nó có thể là chức năng con của “Quản lý đơn hàng”.
Chức năng “Quản lý đơn hàng” ở đây quản lý cho nhiều khách hàng nên sẽ khác với chức năng “Quản lý đơn hàng” của Actor “Khách hàng” nên để phân biệt chúng ta sửa chức năng “Quản lý đơn hàng ” của Actor “Khách hàng” thành “Quản lý đơn hàng cá nhân”. Chức năng “Đăng nhập” có thể dùng chung với Actor “Khách hàng”, chức năng Chat dùng chung với Actor “Khách hàng tiềm năng”.
Khi subject có sự thay đổi trạng thái, nó sẽ duyệt qua danh sách các observer của nó và gọi phương thức cập nhật trạng thái ở từng observer, có thể truyền chính nó vào phương thức để các observer có thể lấy ra trạng thái của nó và xử lý. Lỏng lẻo hóa kết nối: Mẫu Observer giúp giảm độ kết nối giữa các thành phần trong hệ thống, làm cho chúng trở nên độc lập và có thể tái sử dụng một cách dễ dàng. Linhtinh và Tính tái sử dụng: Dễ dàng thêm hoặc loại bỏ Observers mà không cần sửa đổi Subject, tăng tính linh hoạt và tái sử dụng.
Cập nhật không kiểm soát: Mỗi khi có sự thay đổi trong Subject, tất cả các Observers đều được thông báo, có thể dẫn đến các vấn đề hiệu suất và không kiểm soát được số lượng cập nhật. Vấn đề về thứ tự: Thứ tự của việc thông báo đến Observers không được đảm bảo, điều này có thể tạo ra vấn đề nếu có sự phụ thuộc vào thứ tự. Rủi ro về bộ nhớ: Nếu không quản lý cẩn thận, việc giữ các Observers có thể dẫn đến rủi ro về bộ nhớ nếu họ không được loại bỏ khi không còn cần thiết.
Cập nhật liên tục: Nếu trạng thái của Subject thay đổi liên tục, việc thông báo đến Observers có thể tạo ra nhiều cập nhật không cần thiết. Interface IObserver định nghĩa phương thức update() để cập nhật thông tin và ISubject định nghĩa các phương thức để quản lý danh sách các Observer. Các lớp cụ thể (MySQLDBcon, SQLserverDBcon, MongoDBcon) Các lớp này triển khai interface IObserver và cung cấp hành động cụ thể khi có cập nhật hoặc kết nối cơ sở dữ liệu.
Lớp này triển khai interface ISubject và cung cấp cách thức quản lý danh sách các Observer, bao gồm các phương thức attach() detach(), và notifyAllObservers(). Khi có sự thay đổi trong biến môi trường, thông báo được gửi đến tất cả các Observer đã attach để cập nhật và kết nối cơ sở dữ liệu.
Điều này giúp đảm bảo rằng tất cả các khả năng hoạt động của ứng dụng được thử nghiệm, từ đó tránh được những lỗ hổng có thể gây ra sai sót không mong muốn. Điều này giúp nhóm phát triển cải thiện chất lượng phần mềm, từ việc khắc phục những vấn đề cụ thể đến việc tối ưu hóa quy trình phát triển tổng thể. Những lỗi được phát hiện và sửa chữa trước khi ứng dụng ra mắt giúp cho quá trình vận hành, bảo trì và cập nhật sau này trở nên dễ dàng và hiệu quả hơn.
Unit test case: Các nhà phát triển phần mềm thường viết các bài kiểm thử đơn vị cho mã của họ để kiểm tra các đơn vị riêng lẻ, chẳng hạn như mô-đun, quy trình hoặc chức năng, để xác định xem chúng có hoạt động như mong đợi hay không. User interface test case (UI): Điều quan trọng cần nhớ là giao diện người dùng là một phần của hệ thống tổng thể chứ không chỉ là một lớp vỏ nơi chức năng xuất hiện. Các trường hợp kiểm thử giao diện người dùng kiểm tra xem mỗi thành phần giao diện người dùng có hoạt động chính xác, hiển thị và dễ sử dụng hay không.
Security test case: Các trường hợp kiểm tra bảo mật giúp đảm bảo rằng sản phẩm hoặc hệ thống hoạt động bình thường trong mọi điều kiện, kể cả khi người dùng có ý đồ xấu cố gắng truy cập trái phép hoặc làm hỏng hệ thống. User acceptance test case: Các trường hợp kiểm thử chấp nhận của người dùng xác minh rằng ứng dụng đáp ứng các yêu cầu kinh doanh của nó trước khi người dùng chấp nhận nó. Regression testing: Các trường hợp kiểm thử hồi quy xác minh rằng những thay đổi được thực hiện trong quá trình phát triển không khiến bất kỳ chức năng hiện có nào ngừng hoạt động.
Kiểm tra hồi quy xảy ra sau khi thực hiện các thay đổi đối với mã hiện có để kiểm tra xem tất cả chức năng hiện có hoặc chức năng kế thừa có tiếp tục hoạt động như mong đợi sau khi thực hiện các thay đổi hay không. Trong quá trình này, lập trình viên hoặc người đánh giá mã code thực hiện kiểm tra các thành phần như code, yêu cầu kỹ thuật, tài liệu thiết kế, mã nguồn, kịch bản thử nghiệm, để đảm bảo tính chính xác và khả thi của chúng.