Hình 1. Ví dụ về Class Diagram của ATM
Ví dụ trên là Class Diagram của ứng dụng ATM. Tiếp theo chúng ta sẽ bàn kỹ về các thành phần của bản vẽ này và lấy ứng dụng về ATM ở trên để minh họa.
Hình 2. Ký hiệu về Class
Trong đó,
– Class Name: là tên của lớp.
– Attributes (thuộc tính): mô tả tính chất của các đối tượng. Ví dụ như khách hàng có Mã khách hàng, Tên khách hàng, Địa chỉ, Ngày sinh v.v…
– Method (Phương thức): chỉ các hành động mà đối tượng này có thể thực hiện trong hệ thống. Nó thể hiện hành vi của các đối tượng do lớp này tạo ra.
Hình 3. Ví dụ về một Class
Một số loại Class đặc biệt như Abstract Class (lớp không tạo ra đối tượng), Interface (lớp khai báo mà không cài đặt) v.v.. chúng ta xem thêm các tài liệu về lập trình hướng đối tượng để hiểu rõ hơn các vấn đề này.
Hình 4. Ví dụ về Association
Ví dụ quan hệ trên thể hiện Khách hàng nắm giữ Tài khoản và Tài khoản được sở hữu bởi Khách hàng.
+ Aggregation
Aggregation là một loại của quan hệ Association nhưng mạnh hơn. Nó có thể cùng thời gian sống (cùng sinh ra hoặc cùng chết đi)
Hình 5. Ví dụ về Aggregation
Ví dụ quan hệ trên thể hiện lớp Window(cửa sổ) được lắp trên Khung cửa hình chữ nhật. Nó có thể cùng sinh ra cùng lúc.
+ Composition
Composition là một loại mạnh hơn của Aggregation thể hiện quan hệ class này là một phần của class kia nên dẫn đến cùng tạo ra hoặc cùng chết đi.
Hình 5. Ví dụ về Composition
Ví dụ trên class Mailing Address là một phần của class Customer nên chỉ khi nào có đối tượng Customer thì mới phát sinh đối tượng Mailing Address.
+Generalization
Generalization là quan hệ thừa kế được sử dụng rộng rãi trong lập trình hướng đối tượng.
Hình 6. Ví dụ về Genelization
Các lớp ở cuối cùng như Short Term, Long Term, Curent a/c, Savings a/c gọi là các lớp cụ thể (concrete Class). Chúng có thể tạo ra đối tượng và các đối tượng này thừa kế toàn bộ các thuộc tính, phương thức của các lớp trên.
Các lớp trên như Account, Term Based, Transaction Based là những lớp trừu tượng (Abstract Class), những lớp này không tạo ra đối tượng.
Ngoài ra, còn một số quan hệ như khác như dependence, realization nhưng ít được sử dụng nên chúng ta không bàn ở đây.
Hình 7. Các nguồn thông tin có thể tìm Class dự kiến
– Requirement statement: Các yêu cầu. Chúng ta phân tích các danh từ trong các yêu cầu để tìm ra các thực thể.
– Use Cases: Phân tích các Use Case sẽ cung cấp thêm các Classes dự kiến.
– Previous và Similar System: có thể sẽ cung cấp thêm cho bạn các lớp dự kiến.
– Application Experts: các chuyên gia ứng dụng cũng có thể giúp bạn.
Xem xét, ví dụ ATM ở trên chúng ta có thể thấy các đối tượng là Entity Class như sau:
– Customers: khách hàng giao dịch là một thực thể có thật và quản lý trong hệ thống.
– Accounts: Tài khoản của khách hàng cũng là một đối tượng thực tế.
– ATM Cards: Thẻ dùng để truy cập ATM cũng được quản lý trong hệ thống.
– ATM Transactions: Các giao dịch được lưu giữ lại, nó cũng là một đối tượng có thật.
– Banks: Thông tin ngân hàng bạn đang giao dịch, nếu có nhiều nhà Bank tham gia vào hệ thống bạn phải quản lý nó. Lúc đó Bank trở thành đối tượng bạn phải quản lý.
– ATM: Thông tin ATM bạn sẽ giao dịch. Nó cũng được quản lý tương tự như Banks.
Lưu ý: Chỉ các thực thể bên trong hệ thống được xem xét, các thực thế bên ngoài hệ thống không được xem xét. Ví dụ Customers là những người khách hàng được quản lý trong hệ thống chứ không phải người dùng máy ATM bên ngoài. Bạn phải lưu ý điều này để phân biệt Class và Actor.
Hình 8. Ví dụ về Class Diagram cho hệ thống ATM
Cùng nhau học tập, khám phá các kiến thức nền tảng về Lập trình web, mobile, database nhé.
Nền tảng kiến thức - Hành trang tới tương lai hân hạnh phục vụ Quý khách!
Khám phá, trải nghiệm ngay
Vui lòng đăng nhập để gởi bình luận!
Đăng nhậpChưa có bình luận nào!