Chng 6 S LP CLASS DIAGRAMS 1 NI
Có thể bạn quan tâm
- Slides: 101
Chương 6 SƠ ĐỒ LỚP (CLASS DIAGRAMS) 1
NỘI DUNG Sơ đồ lớp thiết kế biểu diễn chi tiết của các lớp phần mềm và giao diện trong một ứng dụng. Những thông tin tiêu biểu trong sơ đồ lớp thiết kế bao gồm: ◦ Các lớp (classes) ◦ Mối quan hệ và thuộc tính (associations & attributes ◦ Giao diện và thao tác trên giao diện (interfaces with their operations) ◦ Các phương thức (methods) ◦ Thuộc tính (attribute) ◦ Các phụ thuộc (dependencies) 2
Định nghĩa sơ đồ lớp Biểu đô lơ p chi ra sư tô n tại cu a ca c lơ p va mô i quan hê giư a chu ng trong ba n thiết kế logic cu a một hê thô ng ▫Chi ra câ u tru c ti nh cu a mô hi nh như lơ p, câ u tru c bên trong cu a chu ng va mô i quan hê vơ i ca c lơ p kha c. ▫Chi ra tâ t ca hoă c một phâ n câ u tru c lơ p cu a một hê thô ng. ▫Không đưa ra ca c thông tin tạm thơ i. • Khung nhi n ti nh cu a một hê thô ng chu yếu hô trơ ca c yêu câ u chư c năng cu a hê thô ng. 3
Định nghĩa sơ đồ lớp Khung nhìn tĩnh của hệ thống 4
Mục đích của sơ đồ lớp • Làm tài liệu cho các lớp cấu thành hệ thống và hệ thốngcon • Mô tả kết hợp, tổng quát hóa và các quan hệ kết tập giữa các lớp trong biểu đồ • Chỉ rõ đặc trưng của lớp, các thuộc tính và tác vụ chính của mỗi lớp • Biểu đồ lớp được dùng khắp nơi trong chu trình phát triển, từ bài toán đến mô hình cài đặt • Tư liệu về cách tương tác với các thư viện lớp có sẵn 5
Định nghĩa sơ đồ lớp Biểu đô lơ p chi ra sư tô n tại cu a ca c lơ p va mô i quan hê giư a chu ng trong ba n thiết kế logic cu a một hê thô ng ▫Chi ra câ u tru c ti nh cu a mô hi nh như lơ p, câ u tru c bên trong cu a chu ng va mô i quan hê vơ i ca c lơ p kha c. ▫Chi ra tâ t ca hoă c một phâ n câ u tru c lơ p cu a một hê thô ng. ▫Không đưa ra ca c thông tin tạm thơ i. • Khung nhi n ti nh cu a một hê thô ng chu yếu hô trơ ca c yêu câ u chư c năng cu a hê thô ng. 6
Domain Model - Design Model Classes Domain model: các lớp khái niệm đại diện cho các khái niệm trừu tượng trong thế giới thực mà người phát triển phần mềm đang quan tâm. Mô hình lớp thiết kế (Design model class): lớp thiết kế đại diện cho các lớp phần mềm, nó được định nghĩa như là một thành phần của phần mềm ứng dụng. 7
Domain Model - Design Model Classes Ví dụ 8
Xây dựng sơ đồ lớp thiết kế Các bước xây dựng sơ đồ lớp thiết kế ◦ Xác định các lớp phần mềm ◦ Xác định các phương thức ◦ Bổ sung các loại thông tin ◦ Tinh chỉnh các mối quan hệ 9
Các cách tiếp cận xác định các lớp 1. Tiếp cận theo thực thể nghiệp vụ 2. Tiếp cận theo cụm danh từ 3. Tiếp cận theo phân loại 4. Tiếp cận theo phân tích hoạt động use case 10
Tiếp cận theo thực thể nghiệp vụ Đối với các thực thể sự vật: kiểm chứng xem có nhu cầu quản lý thông tin về thực thể này trong hệ thống không? Nếu có, xác định một lớp trong sơ đồ phân tích biểu diễn cho thực thể này Xác định tên lớp: tên của sự vật Thuộc tính: bổ sung các thuộc tính mô tả đầy đủ thông tin mà hệ thống có nhu cầu quản lý về đối tượng 11
Tiếp cận theo thực thể nghiệp vụ 12
Tiếp cận theo thực thể nghiệp vụ Đối với thực thể thông tin: Nếu thực thể mô tả thông tin về một hoạt động giao dịch hệ thống thì chuyển thành một lớp trong mô hình phân tích Nếu thực thể là một dạng thông tin tổng hợp có thể tách thành nhiều lớp mới hoặc bổ sung thông tin cho các lớp đang tồn tại 13
Tiếp cận theo thực thể nghiệp vụ 14
Tiếp cận theo thực thể nghiệp vụ 15
Tiếp cận theo cụm danh từ Đề xuất bởi Rebecca Wirfs-Brock, Brian Wilkerson, và Lauren Wiener Ý tưởng: xác định các lớp thông qua việc đọc trong các văn bản mô tả use case hoặc các mô tả yêu cầu để tìm kiếm và trích lọc các cụm danh từ 16
Tiếp cận theo cụm danh từ 17
Tiếp cận theo cụm danh từ Loại bỏ các danh từ không thích hợp 18
Tiếp cận theo cụm danh từ Đồng nhất các ứng viên trùng lắp Các lớp còn lại 19
Danh từ, cụm danh từ có thể là thuộc tính Xác định danh từ, cụm danh từ có thể là thuộc tính: Chỉ được sử dụng như là giá trị Không có nhiều hơn một đặc trưng riêng, hoặc chỉ mô tả một đặc trưng của đối tượng khác Ví dụ: hệ thống ATM (tiếp tục phân tích) Số tiền: một giá trị, không phải một lớp Số dư tài khoản: thuộc tính của lớp Tài khoản PIN không hợp lệ: một giá trị, không phải một lớp Mật khẩu: một thuộc tính (có thể của lớp Khách hàng) Lịch sử giao dịch: một thuộc tính (có thể của lớp Giao dịch) PIN: một thuộc tính (có thể của lớp Khách hàng) 20
Danh từ, cụm danh từ có thể là thuộc tính Danh từ, cụm từ còn lại 21
Danh từ, cụm danh từ có thể là thuộc tính Loại bỏ các ứng viên không mục tiêu hoặc không thuộc phạm vi hệ thống: �� Thông điệp �� Hệ thống �� Mẫu tin �� Ngân quỹ �� VND �� Tiền mặt �� Tiến trình đăng nhập 22
Danh từ, cụm danh từ có thể là thuộc tính ATM: các lớp Máy ATM: cung cấp một giao diện tới ngân hàng Thẻ ATM: cung cấp một khách hàng với một khoá tới một tài khoản Khách hàng: một khách hàng là một cá nhân sử dụng máy ATM, có một tài khoản. Ngân hàng: các khách hàng phụ thuộc vào ngân hàng. Nó là một nơi tập trung các tài khoản và xử lý các giao dịch tài khoản. Tài khoản: nó mô hình hoá một tài khoản của khách hàng và cung cấp các dịch vụ về tài khoản cho khách hàng Giao dịch: mô tả một giao tác của khách hàng khi sử dụng thẻ ATM. Một giao tác được lưu trữ với thời gian, ngày, loại, số tiền, và số dư 23
Xác định các lớp phần mềm Xác định những lớp mà tham gia vào các giải pháp phần mềm. Các lớp này có thể được tìm thấy bằng cách duyệt tất cả các sơ đồ tương tác và danh sách các lớp trong domain model. Tuy nhiên có những lớp trong domain model không cần xuất hiện trong sơ đồ lớp thiết kế 24
Xác định các lớp phần mềm Ví dụ: Một hệ thống máy tính tiền được sử dụng để ghi lại doanh thu và xử lý các khoản thanh toán, được sử dụng trong một cửa hàng bán lẻ, hệ thống bao gồm các thành phần cứng như máy tính và máy quét mã vạch Hệ thống có thể giao tiếp với các ứng dụng khác như máy tính thuế, hệ thống kiểm soát hàng tồn kho, kho lưu trữ sản phẩm theo Loại sản phẩm. Hệ thống tự động xuất hóa đơn thanh toán khi tất cả các sản phẩm mà khách hàng mua được nhập vào hệ thống. 25
Xác định các lớp phần mềm Ví dụ: các lớp khái niệm trong domain model của hệ thống máy tính tiền 26
Xác định các lớp phần mềm Ví dụ: các lớp phần mềm trong hệ thống máy tính tiền 27
Tiếp cận theo phân loại: phân loại các lớp của hệ thống dựa trên các mẫu chung. �� Lớp khái niệm (concept): Một khái niệm là một quan niệm hoặc sự hiểu biết riêng biệt về thế giới. Lớp khái niệm bao gồm các nguyên lý được dùng để tổ chức hoặc để lưu trữ các hoạt động và các trao đổi về mặt quản lý. �� Ví dụ: các lớp khái niệm có thể là: phương pháp, hiệu năng, mô hình, môn học… �� Lớp sự kiện (event): �� Lớp sự kiện là các điểm thời gian cần được lưu trữ. Các sự việc xảy ra tại một thời điểm, hoặc một bước trong một dãy tuần tự các bước �� Ví dụ: đăng ký, hoá đơn, đơn hàng, phiếu nhập, … 28
Tiếp cận theo phân loại Lớp tổ chức (organisation): tập hợp con người, tài nguyên, phương tiện, hoặc những nhóm xác định chức năng người dùng �� Ví dụ: đơn vị, bộ phận, phòng ban, chức danh, … �� Lớp con người (people): lớp con người thể hiện các vai trò khác nhau của người dùng trong việc tương tác với hệ thống. Những đối tượng này thường là người dùng hệ thống hoặc những người không sử dụng hệ thống nhưng thông tin về họ được lưu trữ bởi hệ thống �� Ví dụ: Sinh viên, khách hàng, giáo viên, nhân viên, … 29
Tiếp cận theo phân loại Lớp vị trí (place): Các vị trí vật lý mà hệ thống cần mô tả thông tin về nó. �� Ví dụ: toà nhà, kho, văn phòng, chi nhánh, đại lý, … �� Lớp sự vật hữu hình và thiết bị: các đối tượng vật lý hoặc các nhóm của đối tượng hữu hình mà có thể cảm nhận trực quan và các thiết bị mà hệ thống tương tác. �� Ví dụ: xe hơi, máy bay, … là các sự vật hữu hình; thiết bị cảm ứng nhiệt là một lớp thiết bị. 30
Tiếp cận theo phân loại Ví dụ ATM 31
Tiếp cận theo phân tích hoạt động usecase 32
Tiếp cận theo phân tích hoạt động usecase Phân tích use case “Giải quyết PIN không hợp lệ”. Các hoạt động khách hàng có thể thực hiện với hệ thống: Phân tích use case Rút Tiền Đưa vào thẻ ATM �� Nhập mã PIN �� Rút thẻ ATM �� 33
Phát hiện các đối tượng/Lớp dựa vào lớp phân tích TRẦN THỊ KIM CHI 34
Stereo. Type của lớp TRẦN THỊ KIM CHI 35
Stereo. Type của lớp TRẦN THỊ KIM CHI 36
Xác định các mối liên kết giữa các lớp TRẦN THỊ KIM CHI 37
Stereo. Type của lớp Thí dụ: Giáo viên chọn môn giảng cho mỗi lớp mà mình dạy TRẦN THỊ KIM CHI 38
Stereo. Type của lớp Thí dụ: Giáo viên chọn môn giảng cho mỗi lớp mà mình dạy TRẦN THỊ KIM CHI 39
Stereo. Type của lớp Thí dụ: Giáo viên chọn môn giảng cho mỗi lớp mà mình dạy TRẦN THỊ KIM CHI 40
Stereo. Type của lớp Thí dụ: Giáo viên chọn môn giảng cho mỗi lớp mà mình dạy TRẦN THỊ KIM CHI 41
Xây dựng biểu đồ lớp TRẦN THỊ KIM CHI 42
Xác định mối quan hệ giữa các lớp Xác định mối kết hợp association: Hướng dẫn xác định mối kết hợp: �� Một sự phụ thuộc giữa hai hay nhiều lớp có thể thiết lập thành mối kết hợp. Mối kết hợp thường tương ứng với một động từ hoặc cụm giới từ như là thành phần của, làm việc cho, chứa trong, … �� Một tham chiếu từ một lớp đến một lớp khác là một mối kết hợp. 43
Xác định mối quan hệ giữa các lớp 44
Xác định mối quan hệ giữa các lớp 45
Xác định mối quan hệ giữa các lớp 46
Loại bỏ các mối kết hợp không cần thiết Mối kết hợp đa phân: là mối kết hợp giữa ba lớp trở lên, mối kết hợp này phức tạp trong cách thể hiện Nếu có thể, phát biểu lại nó dùng mối kết hợp nhị phân 47
Loại bỏ các mối kết hợp không cần thiết Mối kết hợp trực tiếp dư thừa: là các mối kết hợp được định nghĩa trong ngữ nghĩa của những mối kết hợp khác (còn gọi là mối kết hợp suy diễn hoặc bắc cầu) 48
Loại bỏ các mối kết hợp không cần thiết Mối kết hợp trực tiếp dư thừa: là các mối kết hợp được định nghĩa trong ngữ nghĩa của những mối kết hợp khác (còn gọi là mối kết hợp suy diễn hoặc bắc cầu) Xác định bản số 49
Loại bỏ các mối kết hợp không cần thiết 50
Loại bỏ các mối kết hợp không cần thiết 51
Loại bỏ các mối kết hợp không cần thiết Nâng cấp mối kết hợp: Xác định mối kết hợp tổng quát – chuyên biệt (generalization): Thể hiện quan hệ kế thừa giữa các lớp và một cấu trúc phân cấp xác định những dòng kế thừa này �� Tiếp cận top-down: �� �� Từ một lớp chúng ta tìm kiếm cụm danh từ chứa tên lớp và tính từ (hoặc danh từ). Đánh giá xem cụm danh từ này có thể là một trường hợp đặc biệt cần được quản lý trong hệ thống không �� Tìm kiếm xem có những đặc trưng riêng của lớp �� Xây dựng mối kết hợp chuyên biệt từ lớp này đến lớp ban đầu 52
Loại bỏ các mối kết hợp không cần thiết 53
Loại bỏ các mối kết hợp không cần thiết Nâng cấp mối kết hợp: Xác định mối kết hợp tổng quát – chuyên biệt (generalization): �� Tiếp cận bottom-up: �� Tìm kiếm trong các lớp để xác định xem có các thuộc tính và phương thức giống nhau. Sau đó chúng ta có thể gom nhóm và đưa các thuộc tính và phương thức chung này lên một lớp tổng quát (trừu tượng) �� Tạo mối kết hợp tổng quát hoá từ các lớp này đến lớp tổng quát mới xác định �� UML/NN 59 54
Loại bỏ các mối kết hợp không cần thiết Vấn đề đa thừa kế: �� Phức tạp trong vấn đề kế thừa �� Không nên sử dụng (phiên bản gốc UML không đưa vào) UML/NN 59 55
Loại bỏ các mối kết hợp không cần thiết Vấn đề đa thừa kế: �� Phức tạp trong vấn đề kế thừa �� Không nên sử dụng (phiên bản gốc UML không đưa vào) UML/NN 59 56
Loại bỏ các mối kết hợp không cần thiết Xác định mối kết hợp thành phần (a-partof, aggregration) �� Đặc trưng cơ bản �� Tính bắc cầu: Nếu lớp A là một thành phần của lớp B và lớp B là thành phần của lớp C lớp A là thành phần của lớp C �� Tính đối xứng: nếu lớp A là thành phần của lớp B thì lớp B không phải là thành phần của lớp A 57
Loại bỏ các mối kết hợp không cần thiết Xác định mối kết hợp thành phần (a-partof, aggregration) �� Tập hợp: một đối tượng vật lý được hình thành từ các đối tượng vật lý thành phần khác 58
Loại bỏ các mối kết hợp không cần thiết Vật chứa: một đối tựơng vật lý chứa đựng các thành phần nhưng không được cấu tạo bởi các thành phần 59
Loại bỏ các mối kết hợp không cần thiết Tập hợp – thành viên: một đối tượng khái niệm chứa các thành phần có thể vật lý hoặc khái niệm He thong ATM 60
Loại bỏ các mối kết hợp không cần thiết Tập hợp – thành viên: một đối tượng khái niệm chứa các thành phần có thể vật lý hoặc khái niệm He thong ATM 61
Xác đinh thuộc tính Câu hỏi: �� Thông tin gì về đối tượng sẽ được quản lý ? �� Nguyên tắc: �� Tên: danh từ; cụm danh từ �� Đơn giản: chỉ dùng đủ thuộc tính để diễn đạt trạng thái đối tượng ở giai đoạn phân tích (thuộc tính sẽ được bổ sung chi tiết hơn ở các giai đoạn tiếp theo) �� Không quá quan tâm về việc phải khám phá hết thuộc tính 62
Xác đinh thuộc tính Lớp Khách Hàng: Phân tích lần lượt tất cả các use case có liên quan đến lớp Khách Hàng như là: “Đăng nhập”, “Xử lý PIN không hợp lệ”. Các thuộc tính của lớp khách hàng như sau: 63
Xác đinh phương thức Các phương thức của mỗi lớp có thể được xác định bằng cách phân tích các biểu đồ tương tác. Nói chung, tập hợp tất cả các Messages được gửi đến một lớp X trên tất cả các sơ đồ tương tác thường là các phương thức của lớp X phải xác định. 64
Xác đinh phương thức Câu hỏi: �� Các đối tượng chịu trách nhiệm xử lý gì về thông tin của nó để cung cấp dịch vụ cho hệ thống? �� Nguyên tắc: �� Tên: động từ + bổ ngữ �� Chỉ quan tâm đến các method có phạm vi toàn cục (public), các method có phạm vi cục bộ sẽ được phát hiện trong giai đoạn thiết kế cài đặt (vd: constructor, …. ) �� Các method chịu trách nhiệm về các thao tác lên các thuộc tính của đối tượng: truy vấn, cập nhật, đọc và ghi 65
Xác đinh phương thức Phân tích các dòng message trong sơ đồ tuần tự để xem có thể chuyển một hoạt động thành một method không? �� Nếu có, đặt tên cho method ứng với hoạt động đó Ví dụ: use case Rút tiền 66
Xác đinh phương thức 67
Tinh chế thuộc tính Kiểu thuộc tính Thuộc tính đơn trị �� Thuộc tính đa trị: có thể dùng các cấu trúc, list, array, bag để khai báo cài đặt. �� Ví dụ: thuộc tính sốĐiện. Thoại của lớp Nhân. Viên có thể là đa trị �� địa. Chỉ[3]: String �� địa. Chỉ[1. . 3]: String �� 68
Tinh chế thuộc tính <phạm vi> <tên> <(danh sách tham số)>: <kiểu trả về> �� Các method đa số là các method có phạm vi toàn cục �� Ví dụ: �� +get_Tên(): String �� +get_SốTài. Khoản(vtài. Khoản : Tài. Khoản): String 70
Xác đinh phương thức Ví dụ: sơ đồ tương tác của hoạt động tính tiền trong hệ thống máy tính tiền 71
Xác đinh phương thức Một số vấn đề với tên phương thức ◦ Thông điệp Create trong sơ đồ tương tác, chỉ ra một đối tượng mới được khởi tạo, khi chuyển thiết kế sang ngôn ngữ lập trình hướng đối tượng, nó phải được thể hiện trong ngữ cảnh của ngôn ngữ hiện thực. ◦ Ví dụ: C ++, Java không có phương thức create() mà là new() 72
Xác đinh phương thức Một số vấn đề với tên phương thức ◦ Một thông điệp dạng (multiobject) truyền tới các đối tượng chứa bên trong lớp đó ◦ Ví dụ: Find() là một thông điệp đến một tập đối tượng ◦ Vì vậy, Find() không phải là một phần của lớp Productspecification; nó là một phần của interface của multiobject. Do đó, không thêm Find() vào lớp Productspecification 73
Bổ sung role vào mối quan hệ Bổ sung điều hướng vào mối quan hệ: ◦ Điều hướng là một thuộc tính của Role, chỉ ra rằng mối quan hệ được thực hiện từ lớp nguồn đến lớp mục tiêu. Ví dụ: 74
Bổ sung role vào mối quan hệ Ví dụ: Sơ đồ lớp của hệ thống máy tính tiền được bổ sung Role vào các mối quan hệ 75
Ví dụ Xây dựng biểu đồ lớp thư viện TRẦN THỊ KIM CHI 76
Ví dụ Xây dựng biểu đồ lớp thư viện TRẦN THỊ KIM CHI 77
Ví dụ Xây dựng biểu đồ lớp thư viện TRẦN THỊ KIM CHI 78
Ví dụ Xây dựng biểu đồ lớp thư viện Tổng quát hóa bằng thừa kế TRẦN THỊ KIM CHI 79
Ví dụ Xây dựng biểu đồ lớp thư viện Tổng quát hóa bằng thừa kế TRẦN THỊ KIM CHI 80
Ví dụ Xây dựng biểu đồ lớp TRẦN THỊ KIM CHI 81
Ví dụ Xây dựng biểu đồ lớp TRẦN THỊ KIM CHI 82
Sử dụng Package tổ chức domain model Để dễ dàng trong phần thiết kế hướng đối tượng, domain model được tổ chức thành các package. Tổ chức domain model thành các package là một thủ tục phức tạp, dựa trên hai nguyên tắc cơ bản: sự gắn kết và độc lập. 83
Nhóm các lớp vào Package Nguyên tắc 1: nhóm các lớp vào package phải thỏa các tiêu chí gắn kết (coherence) sau: ◦ Mục tiêu: các lớp phải trả về các dịch vụ đáp ứng yêu cầu người dùng ◦ Ổn định: sự cô lập các lớp trong một package phải thực sự ổn định trong quá trình phát triển dự án, và sau đó. ◦ Thời gian sống của các đối tượng: tiêu chí này giúp phân biệt được các lớp mà đối tượng có thời gian sống rất khác nhau. Nguyên tắc 2: nhóm các lớp vào package phải giảm thiểu sự phụ thuộc (dependency) giữa các package 84
Nhóm các lớp vào Package Cách chọn các lớp vào một package cần phải: ◦ Có cùng chủ đề, có quan hệ chặt chẽ bởi khái niệm hoặc mục đích ◦ Cùng một hệ thống phân cấp ◦ Tham gia cùng một use case ◦ Có quan hệ kết hợp chặt. 85
Nhóm các lớp vào Package Ký hiệu Package trong UML: được hiển thị như một thư mục dạng tab, Subordinate packages có thể được hiển thị bên trong nó. Tên packages ◦ Nếu package mô tả các phần tử của nó thì tên Package đặt trong tab ◦ Ngược lại, thì tên Package đặt trong package. 86
Quyền sở hữu và tham chiếu Quyền sở hữu: ◦ Một phần tử được sở hữu bởi package chứa nó. ◦ Tuy nhiên, Một phần tử có thể được tham chiếu đến một phần tử trong package khác. Trong trường hợp này, tên của phần tử được xác định bởi tên của package theo định dạng: Package. Name: : Element. Name Ví dụ: 87
Package phụ thuộc Nếu một phần tử trong mô hình phụ thuộc vào một phần tử khác thì giữa chúng có mối quan hệ phụ thuộc Một package phụ thuộc chỉ ra rằng các phần tử bên trong nó kết hợp với các phần tử trong package mục tiêu Trong UML mối quan hệ phụ thuộc được biểu diễn bằng ký hiệu: 88
Package phụ thuộc Ví dụ: package Sales phụ thuộc vào package Core Elements 89
Ví dụ 1 Mô hình package domain của hệ thống máy tính tiền 90
Ví dụ 1 Package Core 91
Ví dụ 1 Package Products 92
Ví dụ 1 Package Sales 93
Bài tập Cho domain model của hệ thống đặt vé máy bay, hãy chia domain model thành 2 package sau cho đảm bảo: ◦ Tính kết dính trong mỗi package ◦ Giảm tối thiểu sự phụ thuộc giữa các package ◦ Dịch vụ của mỗi package là gì? ◦ Đảm bảo tính tái sử dụng 94
Bài tập 95
Bài tập Gợi ý: ◦ Package 1: gồm các lớp liên quan đến chuyến bay ◦ Package 2: các lớp liên quan đến việc đặt vé Lưu ý: ◦ Lớp flight đặt trong Package nào là tốt nhất để đảm bảo thời gian sống và tính tái sử dụng của hệ thống 96
Bài tập Giải pháp 1: 97
Bài tập Giải pháp 2: 98
Bài tập Giải pháp 2: lớp Flight trong package Bookings đảm bảo được các tiêu chí: ◦ Thời gian sống của các đối tượng ◦ Flight có quan hệ chặt hơn với việc đặt vé (Bookings) so với các thông tin chung về chuyến bay. 99
Bài tập Kết quả sơ đồ package 100
Bài tập 101
Từ khóa » Sơ đồ Class Atm
-
Bản Vẽ Sơ đồ Lớp - Class Diagram - IViettech
-
[PDF] THỰC HÀNH XÂY DỰNG BIỂU ĐỒ LỚP, BIỂU ĐỒ TRẠNG THÁI
-
[PDF] 1. CASE STUDY 1: HỆ THỐNG MÁY RÚT TIỀN TỰ ĐỘNG
-
Phân Tích Thiết Kế Hệ Thống Rút Tiền Tự động ATM - Tài Liệu Text - 123doc
-
Phân Tích Thiết Kế Hệ Thống ATM - Tài Liệu Text - 123doc
-
[PDF] Chương 7 XÂY DỰNG SƠ ĐỒ ĐỐI TƯỢNG HỆ THỐNG
-
[PDF] Case Study – ATM System
-
Phân Tích Thiết Kế Hệ Thống Thông Tin Sử Dụng Biểu đồ UML (Phần 2)
-
Cách Vẽ Biểu Đồ Lớp - Hướng Dẫn Cách Thiết Kế Sơ Đồ Lớp
-
Đề Tài ATM | PDF - Scribd
-
[Hệ Thống Thông Tin] Mô Hình Hóa Chức Năng - Use Case Modeling
-
Tạo Biểu đồ Use Case Trực Tuyến - Creately
-
[PDF] Bài 13: Tổng Quan Về UML - Soict