Thực Hành Phân Tích Thiết Kế Hướng Đối Tượng UML (ĐH Công Nghệ TP.HCM)

Chuyên khảo phân tích Thực hành phân tích thiết kế hướng đối tượng, đánh giá các khía cạnh quan trọng, đề xuất hướng nghiên cứu tiếp theo.

Trường đại học

Đại học Công nghệ Tp.HCM

Chuyên ngành

Công nghệ thông tin

Người đăng

Ẩn danh

Thể loại

Giáo trình thực hành

2022

45
0
0

Phí lưu trữ

30 Point

Mục lục chi tiết

MỤC LỤC

1. BÀI 1: HỆ THỐNG QUẢN LÝ THƯ VIỆN

2. BÀI 2: HỆ THỐNG QUẢN LÝ CỬA HÀNG NƯỚC GIẢI KHÁT

3. BÀI 3: HỆ THỐNG QUẢN LÝ KHÁCH SẠN

4. BÀI 4: QUẢN LÝ CHO THUÊ VĂN PHÒNG Ở CAO ỐC

5. BÀI 5: QUẢN LÝ HỒ SƠ BỆNH ÁN CỦA BỆNH NHÂN

6. BÀI 6: QUẢN LÝ CÔNG TY DU LỊCH

7. BÀI 7: QUẢN LÝ NHÂN SỰ

8. BÀI 8: QUẢN LÝ CUỘC ĐUA XE ĐẠP CÚP TRUYỀN HÌNH TP

TÀI LIỆU THAM KHẢO

Tóm tắt

I. Hướng dẫn Phân Tích Thiết Kế Hướng Đối Tượng toàn diện

Phân Tích Thiết Kế Hướng Đối Tượng (OOAD) là một giai đoạn nền tảng và mang tính quyết định trong vòng đời phát triển phần mềm. Theo tài liệu Thực Hành Phân Tích Thiết Kế Hướng Đối Tượng (2022), việc xây dựng một hệ thống thành công phụ thuộc lớn vào khả năng đáp ứng yêu cầu, vòng đời chấp nhận được và tiềm năng phát triển trong tương lai. Cốt lõi của phương pháp này là lập trình hướng đối tượng (OOP), một mô hình tư duy giúp xử lý các vấn đề phức tạp thông qua việc mô hình hóa thế giới thực thành các đối tượng có thuộc tính và hành vi. Để trực quan hóa và chuẩn hóa quá trình này, Ngôn ngữ Mô hình hóa Thống nhất (UML) đã ra đời. Thực hành UML không chỉ là vẽ sơ đồ, mà là một phương pháp giao tiếp hiệu quả giữa các bên liên quan, từ nhà phân tích kinh doanh đến lập trình viên. Bài viết này sẽ cung cấp một cái nhìn tổng quan về Phân Tích Thiết Kế Hướng Đối Tượng, đi sâu vào các khái niệm OOP cốt lõi, và nhấn mạnh vai trò không thể thiếu của các sơ đồ UML trong việc xây dựng các hệ thống phần mềm bền vững, dễ bảo trì và mở rộng.

1.1. Khái niệm cốt lõi của lập trình hướng đối tượng OOP

Cơ sở của Phân Tích Thiết Kế Hướng Đối Tượng chính là tư duy OOP. Phương pháp này xoay quanh bốn đặc tính trụ cột. Thứ nhất là tính đóng gói (Encapsulation), cơ chế che giấu dữ liệu và các phương thức xử lý bên trong một đối tượng, chỉ cho phép tương tác thông qua các giao diện công khai. Điều này bảo vệ sự toàn vẹn của dữ liệu. Thứ hai là tính kế thừa (Inheritance), cho phép một lớp (lớp con) thừa hưởng các thuộc tính và phương thức từ một lớp khác (lớp cha), thúc đẩy khả năng tái sử dụng mã nguồn. Thứ ba là tính đa hình (Polymorphism), cho phép các đối tượng thuộc các lớp khác nhau phản ứng với cùng một thông điệp theo cách riêng của chúng. Cuối cùng là tính trừu tượng (Abstraction), tập trung vào các đặc điểm thiết yếu của một đối tượng và bỏ qua các chi tiết không cần thiết, giúp đơn giản hóa các hệ thống phức tạp.

1.2. Vai trò của UML trong quy trình phát triển phần mềm

UML (Unified Modeling Language) là một ngôn ngữ trực quan tiêu chuẩn được sử dụng để đặc tả, xây dựng và tài liệu hóa các cấu phần của một hệ thống phần mềm. Nó không phải là một phương pháp luận, mà là một công cụ giao tiếp. Các sơ đồ UML đóng vai trò như bản thiết kế chi tiết của một tòa nhà, giúp mọi người hiểu rõ cấu trúc và hành vi của hệ thống trước khi bắt tay vào lập trình. Việc thực hành UML giúp giảm thiểu hiểu lầm, phát hiện sớm các lỗi logic trong thiết kế hệ thống, và tạo ra một tài liệu sống động, dễ dàng cập nhật trong suốt quá trình phát triển. Sử dụng các công cụ như StarUML hay Visual Paradigm giúp quá trình này trở nên hiệu quả và chuyên nghiệp hơn.

II. Vượt qua thách thức trong Phân Tích Thiết Kế Hệ Thống

Nhiều dự án phần mềm thất bại không phải do công nghệ yếu kém mà do giai đoạn phân tích và thiết kế bị xem nhẹ. Tài liệu gốc đã chỉ rõ: “Nếu phần phân tích thiết kế không hoàn chỉnh và đúng đắn thì sẽ dẫn đến việc cài đặt thất bại”. Một trong những thách thức lớn nhất là việc phân tích yêu cầu hệ thống không đầy đủ và chính xác, dẫn đến sản phẩm cuối cùng không đáp ứng được nhu cầu của người dùng. Một hệ thống được thiết kế vội vàng thường thiếu khả năng mở rộng. Khi tổ chức phát triển, hệ thống cũ nhanh chóng trở nên lỗi thời và không thể đáp ứng, gây tốn kém chi phí để làm lại. Việc thiếu một phương pháp luận chặt chẽ như Phân Tích Thiết Kế Hướng Đối Tượng khiến mã nguồn trở nên rối rắm, khó bảo trì và tái sử dụng. Bằng cách áp dụng thực hành UML, các nhóm phát triển có thể xác định rõ ràng các thành phần, mối quan hệ và luồng hoạt động, từ đó giảm thiểu rủi ro và xây dựng nền tảng vững chắc cho việc cài đặt sau này.

2.1. Hậu quả của việc thiếu phân tích yêu cầu hệ thống

Việc bỏ qua hoặc thực hiện sơ sài bước phân tích yêu cầu hệ thống là nguyên nhân gốc rễ của nhiều dự án thất bại. Khi yêu cầu không rõ ràng, đội ngũ phát triển sẽ phải phỏng đoán, dẫn đến việc xây dựng các chức năng không cần thiết hoặc bỏ sót các tính năng quan trọng. Điều này không chỉ lãng phí thời gian và nguồn lực mà còn tạo ra một sản phẩm không giải quyết được vấn đề thực tế của người dùng. Một bản phân tích yêu cầu tốt, được thể hiện qua các sơ đồ ca sử dụng (Use Case Diagram), sẽ là kim chỉ nam cho toàn bộ quá trình, đảm bảo mọi thành viên trong dự án đều có chung một tầm nhìn và mục tiêu.

2.2. Tại sao thiết kế hệ thống sai lầm dẫn đến thất bại

Một thiết kế hệ thống tồi giống như một nền móng yếu. Ban đầu, nó có thể chống đỡ được cấu trúc, nhưng khi hệ thống phát triển và tải trọng tăng lên, các vết nứt sẽ xuất hiện. Các vấn đề phổ biến bao gồm sự phụ thuộc chặt chẽ giữa các module, khó khăn trong việc sửa lỗi và cập nhật, hiệu năng kém và không có khả năng tích hợp với các công nghệ mới. Áp dụng các nguyên lý SOLID và các mẫu thiết kế (design patterns) trong giai đoạn Phân Tích Thiết Kế Hướng Đối Tượng giúp tạo ra một kiến trúc linh hoạt, dễ bảo trì và có khả năng chống chọi với sự thay đổi của yêu cầu trong tương lai.

III. Phương pháp thực hành UML trong Phân Tích Thiết Kế

Việc thực hành UML hiệu quả đòi hỏi sự hiểu biết sâu sắc về các loại biểu đồ khác nhau và mục đích sử dụng của chúng. UML cung cấp một bộ công cụ phong phú để mô hình hóa cả khía cạnh cấu trúc (tĩnh) và hành vi (động) của hệ thống. Trong giai đoạn đầu, sơ đồ ca sử dụng (use case diagram) là công cụ đắc lực để xác định các tác nhân (actors) và các chức năng chính của hệ thống từ góc nhìn người dùng. Tiếp theo, sơ đồ lớp (class diagram) được sử dụng để định nghĩa cấu trúc tĩnh, bao gồm các lớp, thuộc tính, phương thức và các mối quan hệ trong UML như kế thừa, kết tập (aggregation) và hợp thành (composition). Để mô tả hành vi động, sơ đồ tuần tự (sequence diagram)sơ đồ hoạt động (activity diagram) là những lựa chọn không thể thiếu. Chúng giúp trực quan hóa luồng tương tác giữa các đối tượng và quy trình nghiệp vụ một cách rõ ràng. Việc lựa chọn và kết hợp các sơ đồ này một cách hợp lý là chìa khóa để hoàn thiện bản Phân Tích Thiết Kế Hướng Đối Tượng.

3.1. Mô hình hóa yêu cầu với Sơ đồ Ca Sử Dụng Use Case

Một sơ đồ ca sử dụng mô tả sự tương tác giữa người dùng (hoặc hệ thống bên ngoài), được gọi là Actor, và hệ thống đang được phát triển. Mỗi use case đại diện cho một chức năng hoặc một mục tiêu mà Actor muốn đạt được. Ví dụ, trong hệ thống quản lý thư viện, các use case có thể là 'Mượn sách', 'Trả sách', 'Tìm kiếm sách'. Sơ đồ này cực kỳ hữu ích trong giai đoạn phân tích yêu cầu hệ thống vì nó giúp xác định phạm vi của dự án và đảm bảo rằng tất cả các chức năng cần thiết đều được xem xét. Các mối quan hệ như <> và <> giúp làm rõ sự phụ thuộc và các luồng kịch bản tùy chọn, tạo ra một cái nhìn tổng quan nhưng đầy đủ về chức năng hệ thống.

3.2. Thiết kế cấu trúc tĩnh bằng Sơ đồ Lớp Class Diagram

Đây là loại sơ đồ quan trọng nhất trong OOAD, đóng vai trò là bản thiết kế cho mã nguồn. Một sơ đồ lớp thể hiện các lớp trong hệ thống, các thuộc tính (dữ liệu) và phương thức (hành vi) của chúng, cùng các mối quan hệ tĩnh giữa các lớp. Các mối quan hệ chính bao gồm Association (liên kết), Inheritance (kế thừa), và đặc biệt là sự khác biệt tinh tế giữa Aggregation vs Composition. Aggregation biểu thị mối quan hệ 'có một' (has-a) yếu, nơi đối tượng con có thể tồn tại độc lập với đối tượng cha. Ngược lại, Composition là mối quan hệ 'sở hữu' mạnh, nơi đối tượng con không thể tồn tại nếu đối tượng cha bị hủy. Hiểu và áp dụng đúng các mối quan hệ này là rất quan trọng để xây dựng một thiết kế hệ thống chặt chẽ.

3.3. Mô tả luồng hoạt động với Sơ đồ Tuần tự và Hoạt động

Trong khi Class Diagram mô tả 'cái gì', thì sơ đồ tuần tự (sequence diagram)sơ đồ hoạt động (activity diagram) mô tả 'như thế nào'. Sequence diagram tập trung vào sự tương tác giữa các đối tượng theo thứ tự thời gian, hiển thị các thông điệp được gửi và nhận giữa chúng để hoàn thành một use case cụ thể. Nó rất hữu ích để làm rõ logic hoạt động của một chức năng. Mặt khác, Activity diagram lại mô tả luồng công việc hoặc quy trình nghiệp vụ từ điểm bắt đầu đến điểm kết thúc. Nó tương tự như một lưu đồ nhưng mạnh mẽ hơn, hỗ trợ các luồng song song (fork/join) và các điểm quyết định, giúp trực quan hóa các quy trình phức tạp một cách hiệu quả.

IV. Bí quyết tối ưu Thiết Kế Hướng Đối Tượng SOLID và Patterns

Một bản Phân Tích Thiết Kế Hướng Đối Tượng tốt không chỉ dừng lại ở việc vẽ đúng các sơ đồ UML. Để tạo ra một kiến trúc phần mềm thực sự mạnh mẽ, linh hoạt và dễ bảo trì, việc áp dụng các nguyên tắc và kinh nghiệm đã được đúc kết là vô cùng cần thiết. Hai trong số những khái niệm quan trọng nhất chính là nguyên lý SOLID và các mẫu thiết kế (design patterns). SOLID là một tập hợp năm nguyên tắc thiết kế cơ bản giúp giảm thiểu sự phụ thuộc và tăng cường khả năng mở rộng của mã nguồn. Trong khi đó, design patterns là các giải pháp đã được kiểm chứng cho các vấn đề thiết kế phổ biến. Việc kết hợp nhuần nhuyễn giữa việc mô hình hóa bằng UML và áp dụng các nguyên tắc này sẽ nâng tầm bản thiết kế, giúp hệ thống không chỉ hoạt động đúng mà còn có thể phát triển bền vững theo thời gian. Đây chính là sự khác biệt giữa một người chỉ biết vẽ UML và một kiến trúc sư phần mềm thực thụ.

4.1. Giải mã 5 nguyên lý thiết kế SOLID trong OOAD

SOLID là từ viết tắt của năm nguyên tắc thiết kế trong lập trình hướng đối tượng. (S) Single Responsibility Principle - mỗi lớp chỉ nên chịu một trách nhiệm duy nhất. (O) Open/Closed Principle - các thực thể phần mềm nên mở cho việc mở rộng nhưng đóng cho việc sửa đổi. (L) Liskov Substitution Principle - các đối tượng của lớp con phải có thể thay thế các đối tượng của lớp cha mà không làm thay đổi tính đúng đắn của chương trình. (I) Interface Segregation Principle - client không nên bị buộc phải phụ thuộc vào các giao diện mà chúng không sử dụng. (D) Dependency Inversion Principle - các module cấp cao không nên phụ thuộc vào các module cấp thấp, cả hai nên phụ thuộc vào sự trừu tượng. Việc tuân thủ các nguyên lý SOLID giúp tạo ra mã nguồn dễ hiểu, linh hoạt và dễ kiểm thử.

4.2. Giới thiệu các mẫu thiết kế Design Patterns phổ biến

Các mẫu thiết kế là những giải pháp tái sử dụng cho các vấn đề thường gặp trong thiết kế hệ thống. Chúng được chia thành ba nhóm chính: Creational (khởi tạo), Structural (cấu trúc), và Behavioral (hành vi). Ví dụ, mẫu Singleton đảm bảo một lớp chỉ có một thể hiện duy nhất, mẫu Factory cung cấp một giao diện để tạo đối tượng mà không cần chỉ định lớp cụ thể, hay mẫu Observer cho phép một đối tượng thông báo cho các đối tượng phụ thuộc khi trạng thái của nó thay đổi. Việc nhận biết và áp dụng đúng các design patterns giúp tiết kiệm thời gian, tránh các lỗi thiết kế phổ biến và làm cho hệ thống trở nên linh hoạt hơn.

V. Case study Thực hành UML cho hệ thống quản lý thư viện

Lý thuyết sẽ trở nên vô nghĩa nếu không được áp dụng vào thực tế. Tài liệu Thực Hành Phân Tích Thiết Kế Hướng Đối Tượng cung cấp nhiều bài tập thực tiễn, trong đó có hệ thống quản lý thư viện. Đây là một ví dụ kinh điển để minh họa toàn bộ quy trình OOAD. Bắt đầu từ việc phân tích yêu cầu hệ thống, chúng ta xác định các Actor như 'Đọc giả', 'Thủ thư' và các Use Case chính như 'Mượn sách', 'Trả sách', 'Quản lý thẻ'. Từ đó, một sơ đồ lớp (class diagram) chi tiết được xây dựng, định nghĩa các lớp quan trọng như DocGia, Sach, PhieuMuon, NhanVien cùng các thuộc tính và mối quan hệ giữa chúng. Các quy trình nghiệp vụ phức tạp, chẳng hạn như quy trình mượn sách bao gồm kiểm tra thẻ, kiểm tra tình trạng sách và lập phiếu mượn, sẽ được mô tả chi tiết bằng sơ đồ tuần tựsơ đồ hoạt động. Việc thực hành UML trên một case study cụ thể như vậy giúp củng cố kiến thức và phát triển kỹ năng giải quyết vấn đề thực tế.

5.1. Xây dựng Sơ đồ lớp Class Diagram chi tiết cho thư viện

Đối với hệ thống quản lý thư viện, sơ đồ lớp là trái tim của bản thiết kế. Các lớp chính bao gồm NhanVien, DocGia, TheThuVien, DauSach, TheLoai, NhaXuatBan, PhieuMuon, CT_PhieuMuonPhieuPhat. Các thuộc tính quan trọng cần được xác định, ví dụ maDocGia trong lớp DocGia sẽ là khóa chính. Mối quan hệ giữa các lớp cũng cần được làm rõ: DocGia có một TheThuVien (quan hệ 1-1), PhieuMuon có nhiều CT_PhieuMuon (quan hệ Composition, 1-n), và DauSach thuộc về một TheLoai (quan hệ 1-n). Việc xác định chính xác bản số và loại mối quan hệ (aggregation vs composition) sẽ quyết định cấu trúc cơ sở dữ liệu và tính toàn vẹn của hệ thống.

5.2. Minh họa quy trình mượn sách bằng Sơ đồ Tuần tự

Quy trình 'Mượn sách' có thể được mô tả bằng một sơ đồ tuần tự để thể hiện sự tương tác giữa các đối tượng. Sơ đồ sẽ bắt đầu với Actor 'Thủ thư' khởi tạo hành động. 'Thủ thư' gửi thông điệp kiemTraThe() đến đối tượng TheThuVien. Nếu thẻ hợp lệ, một thông điệp kiemTraSach() được gửi đến đối tượng DauSach. Nếu sách có sẵn, 'Thủ thư' sẽ tạo một đối tượng PhieuMuon mới và thêm các chi tiết mượn bằng cách gọi phương thức themSach() trên PhieuMuon. Cuối cùng, số lượng sách trong DauSach được cập nhật. Sequence diagram này giúp làm rõ từng bước của quy trình, xác định trách nhiệm của từng đối tượng và là cơ sở để lập trình viên hiện thực hóa chức năng.

VI. Top công cụ hỗ trợ và tương lai của Phân Tích Thiết Kế

Để việc thực hành UML trở nên hiệu quả, việc sử dụng các công cụ hỗ trợ là không thể thiếu. Các phần mềm như StarUML, Visual Paradigm, hay các công cụ trực tuyến như Lucidchart cung cấp giao diện đồ họa trực quan, giúp người dùng dễ dàng tạo, chỉnh sửa và quản lý các sơ đồ UML. Chúng không chỉ hỗ trợ vẽ mà còn có khả năng kiểm tra tính hợp lệ của mô hình, thậm chí sinh mã nguồn khung từ sơ đồ lớp, giúp đẩy nhanh quá trình phát triển. Nhìn về tương lai, phương pháp OOAD và UML vẫn sẽ là nền tảng quan trọng trong ngành công nghiệp phần mềm. Mặc dù các phương pháp phát triển linh hoạt (Agile) có thể làm thay đổi cách thức áp dụng, nhưng tư duy phân tích và thiết kế có hệ thống, khả năng mô hình hóa các vấn đề phức tạp vẫn là kỹ năng cốt lõi. Việc nắm vững Phân Tích Thiết Kế Hướng Đối Tượng sẽ luôn là một lợi thế cạnh tranh cho bất kỳ kỹ sư phần mềm nào.

6.1. Hướng dẫn sử dụng công cụ StarUML và Lucidchart

Cả StarUMLLucidchart đều là những công cụ mạnh mẽ. StarUML là một phần mềm mã nguồn mở, chuyên dụng cho việc mô hình hóa UML, hỗ trợ đầy đủ các loại biểu đồ và có thể cài đặt trên nhiều hệ điều hành. Nó đặc biệt mạnh mẽ trong việc tạo class diagram và sinh mã. Lucidchart là một công cụ dựa trên nền tảng web, nổi bật với khả năng cộng tác theo thời gian thực, cho phép nhiều người cùng làm việc trên một sơ đồ. Nó có giao diện thân thiện, dễ sử dụng và tích hợp tốt với nhiều nền tảng khác. Tùy thuộc vào nhu cầu cá nhân hay đội nhóm, việc lựa chọn công cụ phù hợp sẽ giúp tối ưu hóa quy trình thiết kế hệ thống.

6.2. Xu hướng phát triển của phương pháp OOAD và UML

Trong bối cảnh phát triển phần mềm hiện đại với các phương pháp Agile và DevOps, vai trò của OOAD và UML đã có sự điều chỉnh. Thay vì tạo ra các tài liệu thiết kế đồ sộ trước khi lập trình (Big Design Up Front), UML hiện được sử dụng một cách linh hoạt hơn, như một công cụ để thảo luận, làm rõ ý tưởng trong các sprint ngắn. Các mô hình được giữ ở mức tối giản, tập trung vào những khía cạnh quan trọng nhất. Sự kết hợp giữa tư duy Phân Tích Thiết Kế Hướng Đối Tượng, các nguyên lý SOLID, và quy trình phát triển lặp lại sẽ tiếp tục là xu hướng chủ đạo, đảm bảo tạo ra các sản phẩm phần mềm chất lượng cao và có khả năng thích ứng nhanh với sự thay đổi.

11/09/2025
Thực hành phân tích thiết kế hướng đối tượng

Trích đoạn nội dung tài liệu

BỘ GIÁO DỤC VÀ ĐÀO TẠO ĐẠI HỌC CÔNG NGHỆ TP.HCM THỰC HÀNH PHÂN TÍCH THIẾT KẾ HƯỚNG ĐỐI TƯỢNG Biên soạn: ThS. Võ Hoàng Khang Website: http://www.vn THỰC HÀNH PHÂN TÍCH THIẾT KẾ HƯỚNG ĐỐI TƯỢNG Ấn bản 2022 MỤC LỤC I MỤC LỤC MỤC LỤC. 2 BÀI 1: HỆ THỐNG QUẢN LÝ THƯ VIỆN. 27 BÀI 2: HỆ THỐNG QUẢN LÝ CỬA HÀNG NƯỚC GIẢI KHÁT.

29 BÀI 3: HỆ THỐNG QUẢN LÝ KHÁCH SẠN. 31 BÀI 4: QUẢN LÝ CHO THUÊ VĂN PHÒNG Ở CAO ỐC. 33 BÀI 5: QUẢN LÝ HỒ SƠ BỆNH ÁN CỦA BỆNH NHÂN. 35 BÀI 6: QUẢN LÝ CÔNG TY DU LỊCH.

37 BÀI 7: QUẢN LÝ NHÂN SỰ. 39 BÀI 8: QUẢN LÝ CUỘC ĐUA XE ĐẠP CÚP TRUYỀN HÌNH TP. 41 TÀI LIỆU THAM KHẢO. 43 II HƯỚNG DẪN HƯỚNG DẪN MÔ TẢ MÔN HỌC Phân tích thiết kế hệ thống là một giai đoạn quan trọng để xây dựng thành công một hệ thống.

Xây dựng một hệ thống được gọi là thành công nếu hệ thống này đáp ứng được các yêu cầu của tổ chức đặt ra, có chu kỳ sống chấp nhận được, và hơn thế nữa có thể phát triển khi hệ thống yêu cầu. Trong thực tế nhiều hệ thống chỉ tồn tại trong một thời gian ngắn và sau đó không còn đáp ứng được nhu cầu của người sử dụng. Một trong những lý do là chưa quan tâm đến giai đoạn phân tích và thiết kế một cách đầy đủ và sâu sắc, để rồi khi tổ chức phát triển thì hệ thống không còn khả năng đáp ứng. Một lý do khác không kém phần quan trọng, là các nhà xây dựng hệ thống không được trang bị một cách đầy đủ các kiến thức và phương pháp cơ bản để có thể tiến hành việc xây dựng một hệ thống.

Nếu phần phân tích thiết kế không hoàn chỉnh và đúng đắn thì sẽ dẫn đến việc cài đặt thất bại. Người học vận dụng được lý thuyết phân tích thiết kế để xây dựng được mô hình dữ liệu quan niệm hay còn gọi là mô hình thực thể kết hợp để xây dựng các đối tượng dữ liệu cơ bản cùng các ký hiệu thích hợp và mô hình hướng đối tượng trong ngôn ngữ UML. Mô hình ERD và UML là 2 mô hình cần thiết và cơ bản để chuyển sang việc tổ chức và cài đặt chương trình quản lý bằng một hệ quản trị cơ sở dữ liệu phù hợp và ngôn ngữ lập trình theo hướng đối tượng. Phương pháp hướng đối tượng giúp chúng ta xử lý các vấn đề phức tạp trong phát triển phần mềm và tạo ra các thế hệ phần mềm có khả năng thích ứng, sử dụng lại bởi tính kế thừa và bền chắc.

Phân tích thiết kế hệ thống là một môn học chính cho các sinh viên chuyên ngành công nghệ thông tin trong các trường đại học và cao đẳng. Đây cũng là một tài liệu tham khảo cần thiết cho những ai quan tâm đến việc phân tích thiết kế hệ thống. Giáo trình thực hành được chia làm 8 bài, mỗi bài đưa ra các ví dụ thực tiễn ở các lĩnh vực trong cuộc sống, những sai lầm có thể xảy ra trong quá trình phân tích thiết kế để phân tích viên khỏi mắc sai sót khi làm việc, giúp cho người đọc thấy được bức tranh toàn cục của hệ thống qua các bước thiết kế. HƯỚNG DẪN III NỘI DUNG MÔN HỌC − Bài 1.

HỆ THỐNG QUẢN LÝ THƯ VIỆN − Bài 2. HỆ THỐNG QUẢN LÝ CỬA HÀNG NƯỚC GIẢI KHÁT − Bài 3. HỆ THỐNG QUẢN LÝ KHÁCH SẠN − Bài 4. QUẢN LÝ CHO THUÊ VĂN PHÒNG Ở CAO ỐC − Bài 5.

QUẢN LÝ HỒ SƠ BỆNH ÁN CỦA BỆNH NHÂN − Bài 6. QUẢN LÝ CÔNG TY DU LỊCH − Bài 7. QUẢN LÝ NHÂN SỰ − Bài 8. QUẢN LÝ CUỘC ĐUA XE ĐẠP CÚP TRUYỀN HÌNH IV HƯỚNG DẪN KIẾN THỨC TIỀN ĐỀ Môn Thực hành phân tích thiết kế hướng đối tượng yêu cầu sinh viên có kiến thức về cơ sở dữ liệu quan hệ, quản trị cơ sở dữ liệu và phân tích thiết kế hệ thống thông tin.

YÊU CẦU MÔN HỌC Học viên vận dụng được lý thuyết phân tích thiết kế để xây dựng được mô hình dữ liệu quan niệm hay còn gọi là mô hình thực thể kết hợp (ERD). Từ mô hình này, người học sẽ vẽ được mô hình lớp (class), từ đó xây dựng các mô hình tương ứng theo yêu cầu đặt ra như: use case, acitivity, sequence…. Sử dụng công cụ để thiết kế mô hình UML phổ biến như Star UML, Astah, Visual Paradigm… Tại các phòng máy thực hành có cài sẵn Star UML, học viên có thể cập nhật phiên bản mới trong quá trình thực hành môn học này. CÁCH TIẾP NHẬN NỘI DUNG MÔN HỌC Để học tốt môn này, học viên cần xem lại kỹ ý nghĩa và cách sử dụng các ký hiệu trong mô hình UML.

Giáo trình này sẽ hướng dẫn cơ bản lại các ký hiệu đó, học viên có thể áp dụng cho các bài tập thực hành theo thứ tự. Sau khi học xong, cần ôn lại bài đã học và làm các bài tập tình huống. Tìm đọc thêm các tài liệu khác liên quan đến bài học và các kiến thức cần thiết trong việc quản lý một hệ thống thông tin. PHƯƠNG PHÁP ĐÁNH GIÁ MÔN HỌC Môn học được đánh giá gồm ba thành phần: − Phần chuyên cần: chiếm 15%, bao gồm đi học đầy đủ các buổi thực hành, đóng góp xây dựng bài.

− Kiểm tra giữa kỳ: chiếm 35%. Hình thức và nội dung đánh giá: SV thực hiện các bài tập trong giờ thực hành và bài kiểm tra giữa kỳ tại phòng thực hành do GV dạy thực HƯỚNG DẪN V hành quy định. GV chấm điểm, giải thích các thắc mắc và công bố công khai sau khi chấm điểm. − Kiểm tra cuối kỳ: chiếm 50%.

Hình thức và nội dung đánh giá: SV thực hiện bài tập kiểm tra cuối kỳ tại phòng thực hành do GV dạy thực hành quy định. GV chấm điểm, giải thích các thắc mắc, sau đó sẽ tổng hợp thành một cột điểm kết thúc môn học và công bố công khai sau khi hoàn thành. VI HƯỚNG DẪN HƯỚNG DẪN SỬ DỤNG STAR UML Học viên có thể download phiên bản mới nhất của Star UML tại website: https://staruml. Với các phần mềm tương tự khác, GV giảng dạy sẽ giới thiệu trong giờ học lý thuyết.

I) Giới thiệu: − Star UML là phần mềm hỗ trợ việc phân tích thiết kế hệ thống thông tin hướng đối tượng. − Nhà sản xuất: MKLab Co, Ltd. − Cài đặt: Xem trong file hướng dẫn hoặc trợ giúp của GV giảng dạy. HƯỚNG DẪN 7 II) Sử dụng: 1) Các ký hiệu và ý nghĩa trong mô hình Use Case (Use Case Diagram): Tên use case là động từ, diễn tả 1 hành động cần thực hiện trong hệ thống.

Tên nên đặt ngắn gọn và rõ nghĩa. Ví dụ: Lập hóa đơn, Rút tiền, Thanh toán… Tên actor là danh từ, biểu diễn loại thực thể đối tượng ngoài hay tổ chức (trong mô hình ERD), các thiết bị có tham gia tương tác trong hệ thống. Ví dụ: Khách hàng, Nhân viên, Ngân hàng, trụ ATM… Mối kết hợp. Chỉ ra mối liên hệ ngữ nghĩa giữa 2 đối tượng.

2 đối tượng trao đổi thông tin qua lại với nhau. Ví dụ: Mối kết hợp có hướng. Chỉ ra mối liên hệ ngữ nghĩa giữa 2 đối tượng. Đối tượng này chuyển thông tin sang đối tượng kia theo chiều mũi tên.

Cần cân nhắc khi dùng ký hiệu này, nếu không rõ chiều di chuyển của dữ liệu, ta nên dùng mối kết hợp vô hướng (Asscociation). Ví dụ: Tổng quát hóa và chuyên biệt hóa. Ví dụ: VIII HƯỚNG DẪN Nhân viên là Tổng quát hóa (lớp Cha), Lễ tân và Phục vụ là Chuyên biệt hóa (lớp Con). Chỉ ra mối liên hệ “Bao gồm”.

Để hoàn thành UseCase A thì phải thực hiện UseCase B và UseCase C (phép AND). UseCase B và C tạo ra nhằm mục đích cho các use case khác kế thừa chức năng. Hạn chế tạo ra các use case quá nhỏ. Ví dụ: HƯỚNG DẪN 9 Chỉ ra mối liên hệ “Mở rộng”.

Trong quá trình thực thi UseCase A, trong một số trường hợp phải thực hiện UseCase B (không bắt buộc). Trong cả 2 trường hợp <<include>> và <<extend>> trên, UseCase A được gọi là Use Case cơ sở (Base Use Case). Ví dụ: X HƯỚNG DẪN Khi mượn sách, nếu đọc giả chưa có thẻ thì có thể gọi chức năng “Cấp Thẻ Thư viện”, nếu thẻ quá hạn thì có thể gọi chức năng “Gia hạn Thẻ Thư viện”, ngược lại thì không gọi các chức năng này (không bắt buộc). Chỉ ra mối liên hệ “Phụ thuộc”.

Hành động này phụ thuộc vào một hành động khác đã thực hiện trước. Khi đọc giả trả sách, NV thư viện sẽ tìm Phiếu mượn sách tương ứng, mở CT_PMS (đã lưu trữ trước đó), nhập vào Ngày trả, Chọn các sách cần trả rồi chọn Tình trạng sách tương ứng (Mất/Rách/Trễ/Bình thường.), cần thiết thì lập Phiếu phạt. Như vậy hành động trả sách phụ thuộc vào dữ liệu mượn sách đã lưu trữ trước đó (CT_PMS). Ta dùng ký hiệu Dependency nối từ ô “Trả sách” sang ô “Nhập CT_PMS” để chỉ ra sự phụ thuộc (Trong trường hợp này, ta sử dụng ký hiệu <<include>> vẫn hợp lý).

Các ký hiệu và ý nghĩa trong mô hình Class (Class Diagram): Ký hiệu Class. Bao gồm các thuộc tính và phương thức (hành vi). R-Click vào class để chọn chức năng cần thực hiện. Add -> Attribute: thêm thuộc tính.

Add -> Operation: thêm phương thức. Để chỉ định thuộc tính định danh (như PK trong ERD), ta chọn isID ở cửa sổ bên phải. XII HƯỚNG DẪN Trong cơ sở dữ liệu quan hệ, như SQL Server, Attribute tương ứng với Field (Thuộc tính), Operation tương ứng với Function (Hàm) hay Stored Procedure (Thủ tục). Ví dụ: Các ký hiệu và có ý nghĩa tương tự bên mô hình Use Case.

Tổng hợp/Tập hợp (Aggregation). Tập hợp là một kiểu liên kết đặc biệt trong đó các đối tượng được lắp ráp hoặc cấu hình với nhau để tạo ra một đối tượng phức tạp hơn. Đây chính là quan hệ Cha-Con trong mô hình ERD. Chú ý: Khi sửa Cha thì Con sửa theo (giá trị của khóa ngoại), xóa Cha thì giá trị của khóa ngoại của Con được thiết lập là NULL hoặc bằng 1 giá trị default (on update cascade on delete set null).

Ví dụ: HƯỚNG DẪN 13 Chú ý cặp bản số đặt ngược lại so với mô hình ERD. Thành phần là một trường hợp kết hợp đặc biệt mô tả mối quan hệ giữa một tổng thể và các bộ phận tồn tại của nó. Nói một cách đơn giản, trong một bố cục, một phần không bao giờ có thể lớn hơn toàn bộ. Ví dụ: Một tòa nhà bao gồm các phòng.

Trong mô hình ERD, thành phần cũng chỉ ra mối quan hệ Cha-Con.

Nội dung được bảo vệ bản quyền — Tải xuống đầy đủ