THIẾT KẾ HƯỚNG ĐỐI TƯỢNG
Hệ thống
Hệ thống là những phần tử có ràng buộc, tương tác lẫn nhau cùng đạt được mục đích nhất định, hay gây ra những tác động nhất định.
Ví dụ: Hệ mặt trời, hệ thống các trường đại học, hệ thống các ngành sản xuất… b Các đặc trưng của hệ thống:
Liên hệ giữa các thành phần
Giao diện (interface) Đầu vào (input) Đầu ra (output)
Cửa hàng chuyên cung cấp sỉ và lẻ các loại bánh kẹo, rượu bia, phục vụ cho khách hàng có nhu cầu mua sắm Đối tác của cửa hàng bao gồm các nhà cung cấp, là những công ty sản xuất bánh kẹo và rượu bia, cung cấp hàng hóa cho cửa hàng Ngoài ra, ngân hàng cũng có vai trò quan trọng trong việc giao tiếp với cửa hàng thông qua các giao dịch gửi, rút và thanh toán tiền mặt cho nhà cung cấp.
Hệ thống thông tin
Hệ thống này bao gồm các yếu tố liên kết chặt chẽ với nhau, thực hiện chức năng thu thập, xử lý, lưu trữ và phân phối thông tin cùng dữ liệu, đồng thời cung cấp cơ chế phản hồi nhằm đạt được mục tiêu đã được xác định trước.
Các tổ chức có thể tận dụng hệ thống thông tin cho nhiều mục đích khác nhau Trong quản trị nội bộ, hệ thống này hỗ trợ tạo ra sự hiểu biết chung, đồng nhất hành động và củng cố sức mạnh tổ chức, từ đó mang lại lợi thế cạnh tranh Đối với bên ngoài, hệ thống thông tin giúp thu thập thông tin chi tiết về khách hàng, cải tiến dịch vụ và nâng cao khả năng cạnh tranh, góp phần thúc đẩy sự phát triển bền vững.
Các thành phần cấu thành hệ thống thông tin
Hệ thống thông tin thông thường được cấu thành bởi:
Các thiết bị và phương tiện kỹ thuật chủ yếu được sử dụng để xử lý và lưu trữ thông tin bao gồm máy tính cùng với các thiết bị ngoại vi, giúp nhập và xuất dữ liệu hiệu quả.
Gồm các chương trình máy tính, các phần mềm hệ thống, các phần mềm chuyên dụng, thủ tục dành cho người sử dụng.
Ví dụ: Các hệ thống mạng để truyền dữ liệu
Con người trong hệ thống thông tin.
Chu trình của hệ thống
1.2.1 Vòng đời phát triển của hệ thống
1.2.2 Các bước phát triển hệ thống
Giai đoạn 1: Khảo sát dự án
Khảo sát hiện trạng là bước đầu tiên trong việc phát triển hệ thống thông tin, với nhiệm vụ chính là thu thập thông tin cần thiết để đáp ứng các yêu cầu của dự án Giai đoạn này được chia thành hai bước quan trọng.
Khảo sát sơ bộ là quá trình tìm hiểu các yếu tố cơ bản như tổ chức, văn hóa, đặc trưng và con người, nhằm tạo nền tảng vững chắc cho việc phát triển hệ thống thông tin (HTTT) phù hợp với dự án và doanh nghiệp.
Khảo sát chi tiết là quá trình thu thập thông tin quan trọng về hệ thống, bao gồm chức năng xử lý, thông tin được phép nhập và xuất, các ràng buộc, giao diện cơ bản và nghiệp vụ Những dữ liệu này đóng vai trò thiết yếu trong việc phân tích và thiết kế hệ thống hiệu quả.
Bước 2: Đặt ra các vấn đề trọng tâm cần phải giải quyết, như:
Thông tin đưa vào hệ thống phải như thế nào?
Dữ liệu hiển thị và xuất ra khác nhau ở những điểm nào?
Ràng buộc giữa các đối tượng trong hệ thống cần xây được dựng ra sao?
Hệ thống cần phải đáp ứng các yêu cầu về chức năng và quy trình xử lý để đảm bảo hiệu quả hoạt động Việc lựa chọn giải pháp phù hợp là rất quan trọng, và cần xem xét tính khả thi của từng giải pháp để đảm bảo rằng chúng có thể được triển khai một cách hiệu quả.
Dựa trên thông tin thu thập và các vấn đề xác định trong giai đoạn khảo sát, nhà quản trị và chuyên gia sẽ lựa chọn các yếu tố cần thiết để xây dựng hệ thống thông tin phù hợp cho doanh nghiệp.
Giai đoạn 2: Phân tích hệ thống
Mục tiêu của giai đoạn là xác định các thông tin và chức năng xử lý của hệ thống, cụ thể như sau:
Xác định yêu cầu của hệ thống thông tin (HTTT) bao gồm các chức năng chính và phụ, nghiệp vụ cần xử lý để đảm bảo tính chính xác, tuân thủ các văn bản luật và quy định hiện hành Đồng thời, hệ thống cần đảm bảo tốc độ xử lý hiệu quả và khả năng nâng cấp trong tương lai.
Phân tích và đặc tả mô hình phân cấp chức năng tổng thể được thực hiện qua sơ đồ BFD (Business Flow Diagram) Từ mô hình BFD, chúng ta sẽ phát triển mô hình luồng dữ liệu DFD (Data Flow Diagram) bằng cách phân rã chức năng theo các mức 0, 1, 2 tại từng ô xử lý.
Phân tích bảng dữ liệu là bước quan trọng trong việc xây dựng hệ thống thông tin Cần xác định các bảng dữ liệu cần thiết, bao gồm các trường dữ liệu phù hợp Đồng thời, việc xác định khóa chính và khóa ngoại cũng như mối quan hệ giữa các bảng dữ liệu là cần thiết để đảm bảo tính toàn vẹn và khả năng truy cập thông tin hiệu quả.
Trong giai đoạn này, các chuyên gia sẽ tiến hành đặc tả sơ bộ các bảng dữ liệu trên giấy để có cái nhìn tổng quan và xác định các giải pháp tối ưu cho hệ thống Điều này đảm bảo rằng các yêu cầu đã khảo sát được thực hiện chính xác trước khi triển khai trên các phần mềm chuyên dụng.
Các chuyên gia sẽ sử dụng thông tin thu thập từ khảo sát và phân tích để chuyển hóa vào phần mềm chuyên dụng, nhằm thiết kế hệ thống chi tiết Giai đoạn này được chia thành hai bước quan trọng.
Bước 1: Thiết kế tổng thể
Dựa trên các bảng dữ liệu đã được phân tích và đặc tả, mô hình mức ý niệm sẽ được thiết kế bằng phần mềm chuyên dụng như Sybase.
PowerDesigner và CA ERwin Data Modeler cho phép các chuyên gia hình dung mối quan hệ giữa các đối tượng thông qua mô hình mức ý niệm, từ đó cung cấp cái nhìn tổng quát trước khi chuyển đổi sang mô hình mức vật lý.
Bước 2: Thiết kế chi tiết
Thiết kế cơ sở dữ liệu (Database): Với mô hình mức vật lý hoàn chỉnh ở giai đoạn thiết kế đại thể sẽ được kết sinh mã thành file sql.
Thiết kế truy vấn, thủ tục, hàm: thu thập, xử lý thông tin nhập và đưa ra thông tin chuẩn xác theo đúng nghiệp vụ.
Thiết kế giao diện chương trình đảm bảo phù hợp với môi trường, văn hóa và yêu cầu của doanh nghiệp thực hiện dự án.
Thiết kế chức năng chương trình đảm bảo tính logic trong quá trình nhập liệu và xử lý cho người dùng.
Chúng tôi cung cấp dịch vụ thiết kế báo cáo tùy chỉnh, dựa trên yêu cầu cụ thể của từng doanh nghiệp và các quy định hiện hành Điều này cho phép doanh nghiệp có những mẫu báo cáo phù hợp hoặc tự tạo mẫu báo cáo ngay trên hệ thống của mình.
Thiết kế các kiểm soát thông qua việc cung cấp thông báo, cảnh báo hoặc lỗi cụ thể nhằm tạo sự tiện lợi và kiểm soát chặt chẽ quá trình nhập liệu, từ đó nâng cao độ chính xác của dữ liệu.
Thiết kế là quá trình sử dụng công cụ, phương pháp và thủ tục để phát triển mô hình hệ thống cần thiết Sản phẩm cuối cùng của giai đoạn này là đặc tả hệ thống, cho phép lập trình viên và kỹ sư phần cứng dễ dàng chuyển đổi thành chương trình và cấu trúc hệ thống thực tế.
Giai đoạn 4: Thực hiện Đây là giai đoạn nhằm xây dựng hệ thống theo các thiết kế đã xác định Giai đoạn này bao gồm các công việc sau:
Lựa chọn hệ quản trị cơ sở dữ liệu (SQL Server, Oracle, MySQL, …) và cài đặt cơ sở dữ liệu cho hệ thống.
Lựa chọn công cụ lập trình để xây dựng các modules chương trình của hệ thống (Microsoft Visual Studio, PHP Designer, ).
Lựa chọn công cụ để xây dựng giao diện hệ thống (DevExpress, Dot Net
Viết tài liệu hướng dẫn sử dụng, tài liệu kỹ thuật hoặc clip hướng dẫn.
Trước hết phải lựa chọn công cụ kiểm thử.
Kiểm chứng các modules chức năng của hệ thống thông tin, chuyển các thiết kế thành các chương trình (phần mềm).
Thử nghiệm hệ thống thông tin.
Cuối cùng là khắc phục các lỗi (nếu có).
Viết test case theo yêu cầu.
Kết quả cuối cùng là một hệ thống thông tin đạt yêu cầu đặt ra.
Giai đoạn 6: Triển khai và bảo trì
Lắp đặt phần cứng để làm cơ sở cho hệ thống.
Phân tích và thiết kế hệ thống
Phân tích và thiết kế hệ thống thông tin là phương pháp quan trọng để xây dựng và duy trì hệ thống thông tin, nhằm thực hiện các chức năng cơ bản như lưu trữ, xử lý và truyền thông tin Mục tiêu chính của quá trình này là cải tiến cấu trúc hệ thống thông qua các quy trình, đặc biệt là ứng dụng phần mềm, giúp người dùng hoàn thành công việc một cách dễ dàng và hiệu quả Là người phân tích hệ thống, bạn sẽ đóng vai trò trung tâm trong sự phát triển phần mềm này.
- Sự hiểu biết của bạn về các mục tiêu, các cấu trúc và các qui trình của tổ chức.
Kiến thức vững vàng về tin học và chuyên môn sâu trong lĩnh vực sẽ giúp triển khai công nghệ thông tin hiệu quả, mang lại lợi ích thiết thực cho tổ chức theo yêu cầu.
Trong quá trình phát triển phần mềm, không có sản phẩm nào hoàn hảo ngay từ đầu, do đó việc nghiên cứu nhu cầu và đánh giá hiện trạng trước khi thiết kế là rất quan trọng Điều này không chỉ giúp giảm chi phí phát triển hệ thống mà còn đảm bảo rằng phần mềm đáp ứng đúng yêu cầu Thường thì các nhà đầu tư chỉ đưa ra yêu cầu mơ hồ như “Phần mềm quản lý ” hoặc “Trang tin điện tử của đơn vị ”, mà không chỉ rõ vấn đề cụ thể cần được tin học hóa.
Khi vận hành, nhà đầu tư thường chỉ chú trọng đến nhu cầu trực tiếp mà bỏ qua tổng thể của hệ thống, dẫn đến việc không xem xét mối liên hệ giữa các nhóm trong đơn vị và các quy định, quy trình hiện có Do đó, cần thiết phải áp dụng một phương pháp khoa học để hướng dẫn thực hiện dự án tin học hóa, tùy thuộc vào mô hình phát triển Có nhiều quan điểm khác nhau về cách tiếp cận vấn đề và việc phân tích.
Phân tích và thiết kế hướng đối tượng
Trong quy trình phát triển phần mềm, các giai đoạn chính bao gồm thu thập và phân tích yêu cầu, thiết kế hệ thống, phát triển, kiểm thử, triển khai và bảo trì Giai đoạn phân tích và thiết kế là giai đoạn khó khăn và phức tạp nhất, giúp làm rõ yêu cầu, xác định giải pháp và mô tả chi tiết cách thức thực hiện Nó trả lời hai câu hỏi quan trọng: phần mềm này làm gì và làm như thế nào Một phương pháp phổ biến trong phân tích và thiết kế phần mềm là Phân tích thiết kế hướng đối tượng (OOAD), trong đó hệ thống được xem như tập hợp các đối tượng tương tác với nhau, giúp hiểu rõ hơn về cấu trúc và chức năng của hệ thống.
UML (Unified Modeling Language) là ngôn ngữ mô hình hóa được sử dụng để biểu diễn hệ thống thông qua các bản vẽ thiết kế Những bản vẽ này giúp các nhóm thiết kế giao tiếp hiệu quả và hỗ trợ quá trình phát triển hệ thống, đồng thời thuyết phục khách hàng và nhà đầu tư Tương tự như trong ngành xây dựng, nơi các bản vẽ thiết kế hướng dẫn và kiểm soát thi công, UML đóng vai trò quan trọng trong việc mô tả và phát triển hệ thống.
OOAD yêu cầu các bản vẽ để mô tả hệ thống thiết kế, trong khi UML là ngôn ngữ dùng để biểu diễn các bản vẽ này Do đó, việc phân tích và thiết kế theo hướng đối tượng thường được kết hợp với việc sử dụng UML để thể hiện các thiết kế, tạo thành một mối quan hệ chặt chẽ giữa hai khái niệm này.
Phân biệt giữa thiết kế hướng đối tượng và thiết kế hướng chức năng
Phương pháp hướng chức năng là một cách tiếp cận truyền thống trong ngành Công nghệ phần mềm, tập trung vào việc xác định và lưu trữ thông tin cần thiết cho người dùng Chúng ta bắt đầu bằng việc thu thập yêu cầu từ người dùng về các thông tin họ cần, sau đó thiết kế ngân hàng dữ liệu để lưu trữ những thông tin đó Phương pháp này cũng bao gồm việc cung cấp các biểu mẫu để nhập dữ liệu và tạo báo cáo để trình bày thông tin Tuy nhiên, cách tiếp cận này chủ yếu chú trọng vào dữ liệu mà ít quan tâm đến cách thức hoạt động và ứng xử của hệ thống Đây là phương pháp đã được áp dụng rộng rãi để phát triển hàng ngàn hệ thống trong nhiều năm qua.
Lối tiếp cận xoay quanh dữ liệu rất hiệu quả cho thiết kế ngân hàng dữ liệu và quản lý thông tin, nhưng khi áp dụng cho thiết kế ứng dụng, nó có thể gây ra nhiều khó khăn Thách thức lớn nhất là việc yêu cầu hệ thống thường xuyên thay đổi Mặc dù hệ thống xoay quanh dữ liệu có khả năng xử lý thay đổi trong ngân hàng dữ liệu một cách dễ dàng, nhưng việc thực hiện các thay đổi liên quan đến nguyên tắc nghiệp vụ hay cách thức hoạt động của hệ thống lại trở nên phức tạp.
Phương pháp hướng đối tượng được phát triển nhằm giải quyết vấn đề bằng cách tập trung vào hai khía cạnh quan trọng: thông tin và cách thức hoạt động.
Phương pháp hướng đối tượng:
Hướng đối tượng là một thuật ngữ phổ biến trong ngành công nghiệp phần mềm, với nhiều công ty đang nỗ lực áp dụng công nghệ này vào ứng dụng của họ Hiện nay, hầu hết các ứng dụng đều mang tính chất hướng đối tượng, nhưng khái niệm này thực sự có nghĩa là gì?
Lối tiếp cận hướng đối tượng là phương pháp tư duy giúp ánh xạ các thành phần của bài toán vào các đối tượng trong thực tế Bằng cách chia ứng dụng thành các đối tượng độc lập, chúng ta có thể xây dựng ứng dụng bằng cách kết hợp những đối tượng này Hãy hình dung như việc xây dựng lâu đài từ các mẫu gỗ: trước tiên, bạn cần tạo hoặc mua các mẫu gỗ cơ bản để làm khối xây dựng Khi đã có những khối này, bạn có thể ghép chúng lại để tạo thành lâu đài Tương tự, khi đã xây dựng một số đối tượng cơ bản trong máy tính, bạn có thể kết hợp chúng để phát triển ứng dụng của mình.
Một ví dụ đơn giản về việc rút tiền mặt tại ngân hàng cho thấy rằng các thành phần như tài khoản, nhân viên và khách hàng chính là những “mẫu gỗ” phản ánh các đối tượng trong thực tế Ứng dụng sẽ được nhận diện và cung cấp giải pháp liên quan đến các đối tượng này, giúp cải thiện trải nghiệm người dùng.
Phương Phân tích thiết kế hướng Cấu
Phân tích thiết kế hướng đối tượng pháp trúc
Phương pháp hướng chương trình con khác biệt so với phương pháp hướng cấu trúc ở chỗ nó không chỉ tập trung vào việc phân chia dữ liệu hoặc chương trình chính thành nhiều phần, mà còn chú trọng vào thực thể đối tượng Điều này giúp cải thiện tính linh hoạt và khả năng tái sử dụng mã, đồng thời cân bằng giữa dữ liệu và hành động trong quá trình phát triển phần mềm.
Cách tiếp cận hướng dữ liệu và hướng đối tượng trong phát triển phần mềm tập trung vào việc xác định các thành phần của hệ thống dựa trên dữ liệu và hành động Phương pháp này cho phép phân chia hệ thống thành các phần nhỏ hơn, gọi là phân tích hệ thống, nơi mỗi đối tượng thực hiện các chức năng liên quan đến dữ liệu và hành động cụ thể Các đối tượng này tương đối độc lập, và phần mềm được xây dựng bằng cách kết hợp chúng thông qua các mối quan hệ, từ đó đáp ứng các yêu cầu của bài toán thực tế.
Phương pháp thiết kế từ trên xuống (top-down) và từ dưới lên (bottom-up) là hai cách tiếp cận quan trọng trong việc quan hệ và tương tác giữa các đối tượng Phương pháp top-down bắt đầu từ cái nhìn tổng thể, sau đó phân chia thành các bài toán nhỏ hơn Ngược lại, phương pháp bottom-up tiến hành phân tích các thuộc tính cụ thể của từng đối tượng, từ đó xây dựng và trừu tượng hóa thành các bài toán có thể cài đặt được Sự kết hợp giữa hai phương pháp này giúp tối ưu hóa quá trình thiết kế và phát triển hệ thống.
Phương pháp này nổi bật với việc dữ liệu được đóng gói để hạn chế tái sử dụng mã nguồn, từ đó tiết kiệm tài nguyên và công sức lập trình Ngược lại, phương pháp truy cập tự do cho phép truy cập trực tiếp vào cấu trúc dữ liệu, thể hiện mối quan hệ chặt chẽ giữa giải thuật và cấu trúc dữ liệu.
Tư duy phân tích thiết kế rõ ràng và gần gũi với thế giới thực giúp nâng cao khả năng tái sử dụng và làm cho chương trình trở nên dễ hiểu hơn Việc đóng gói thông tin một cách hợp lý không chỉ che giấu các chi tiết phức tạp mà còn làm cho hệ thống trở nên tin cậy hơn.
+ Phân tích được các chức năng + Thừa kế làm giảm chi phí, hệ của hệ thống thống có tính mở cao hơn
+ Dễ theo dõi luồng dữ liệu + Xâu dựng hệ thống phức tạp.
Phương pháp này không hỗ trợ việc sử dụng lại các mô-đun trong phần mềm khác với các yêu cầu dữ liệu khác, do tính phức tạp và cấu trúc phụ thuộc chặt chẽ vào dữ liệu đầu vào Các chương trình hướng cấu khó theo dõi luồng dữ liệu, khiến cho việc áp dụng và giải quyết bài toán trở nên khó khăn.
+ Không phù hợp cho phát triển các phần mềm lớn.
+ khó quản lý mối quan hệ giữa các modul và dễ gây ra lỗi trong phân tích cũng như khó kiểm thử và bảo trì.
Phương pháp hướng cấu trúc và phương pháp hướng đối tượng là hai kỹ thuật quan trọng thường được áp dụng cho các bài toán lớn và phức tạp Những phương pháp này đặc biệt hữu ích khi xử lý nhiều luồng dữ liệu nhỏ với các yêu cầu khác nhau Để giải quyết hiệu quả, cần có một cách tiếp cận rõ ràng trong việc xây dựng giải thuật.
Lĩnh vực trúc không thể quản lý hiệu quả nếu không áp dụng phương pháp hướng đối tượng Phương pháp này giúp lập trình viên tận dụng khả năng tự quản lý và truy cập dữ liệu, đồng thời bảo vệ thông tin và tiết kiệm công sức cũng như tài nguyên.
Một số kỹ năng cần có của người thiết kế hệ thống hướng đối tượng
- Có kiến thức kỹ thuật về phần cứng hiện hành và đặc tính của chúng.
- Biết các phần mềm và ngôn ngữ lập trình viên sử dụng.
- Có khả năng sáng tạo và khả năng hình dạng tốt khi tạo bản thiết kế
- Phải có kiên thức thực tế rộng.
- Có khả năng diễn đạt và truyền đạt tốt cho nhà quản lý và những người chưa biết.
- Có ý thức kỷ luật cao, kiên định để bám sát một cách tiếp cận nhưng đủ mềm dẻo để tiếp cận và vận dụng những ý tưởng mới tiếp cận.
- Có khả năng điều hoà, giao tiếp tốt với cán bộ, nhân viên.Lịch sử phân tích và thiết kế hướng đối tượng.
NGÔN NGỮ THIẾT KẾ HƯỚNG ĐỐI TƯỢNG - UML
Giới thiệu tổng quan về UML
UML là một ngôn ngữ chuẩn để xác định, hình dung, xây dựng, và ghi lại các hiện vật của hệ thống phần mềm.
UML đã được tạo ra bởi Nhóm Quản lý Đối tượng (OMG) và dự thảo đặc tả UML 1.0 đã được đề xuất cho OMG vào tháng 1 năm 1997.
OMG liên tục nỗ lực để tạo ra một chuẩn công nghiệp thực sự.
- UML là viết tắt của Unified Modeling Language
- UML khác với các ngôn ngữ lập trình phổ biến khác như C ++, Java, COBOL, etc.
- UML là một hình ảnh ngôn ngữ được sử dụng để làm cho các bản thiết kế phần mềm.
UML là một ngôn ngữ mô hình hóa trực quan đa mục đích, được sử dụng để hình dung, xác định, phát triển và tài liệu hóa các hệ thống phần mềm.
UML không chỉ được áp dụng trong việc mô hình hóa hệ thống phần mềm mà còn có thể được sử dụng để mô hình hóa các hệ thống không phải phần mềm, chẳng hạn như luồng quy trình trong một đơn vị sản xuất.
UML không phải là ngôn ngữ lập trình, nhưng có thể sử dụng các công cụ để tạo mã từ sơ đồ UML bằng nhiều ngôn ngữ khác nhau UML liên quan chặt chẽ đến phân tích và thiết kế theo định hướng đối tượng, và sau khi được chuẩn hóa, nó đã trở thành một tiêu chuẩn của OMG.
Một bức tranh trị giá một ngàn chữ, câu nói này phản ánh chính xác bản chất của UML Các khái niệm hướng đối tượng đã được giới thiệu từ trước, nhưng không có phương pháp chuẩn nào để tổ chức và củng cố phát triển hướng đối tượng Sự ra đời của UML đã đáp ứng nhu cầu này.
Một trong những mục tiêu quan trọng trong việc phát triển UML là xác định các ngôn ngữ mô hình hóa chung, dễ hiểu và dễ sử dụng cho tất cả người lập mô hình.
Biểu đồ UML phục vụ cho cả nhà phát triển lẫn người dùng doanh nghiệp và những người muốn hiểu rõ về hệ thống, bao gồm cả hệ thống phần mềm và phi phần mềm Điều quan trọng là UML không chỉ là một phương pháp phát triển, mà nó còn đi kèm với các quy trình cần thiết để đảm bảo sự thành công của hệ thống.
Tóm lại, UML được định nghĩa là một công cụ mô hình hóa đơn giản, giúp mô tả và quản lý các hệ thống phức tạp trong môi trường hiện đại.
Mô hình khái niệm của UML là công cụ quan trọng giúp định hình và tổ chức thông tin trong phát triển phần mềm Để hiểu rõ về mô hình khái niệm, trước tiên chúng ta cần xác định khái niệm này là gì và lý do tại sao nó lại cần thiết trong quá trình thiết kế hệ thống Mô hình khái niệm không chỉ giúp truyền đạt ý tưởng mà còn hỗ trợ việc phân tích và thiết kế hiệu quả hơn.
- Một mô hình khái niệm có thể được định nghĩa như là một mô hình được làm bằng các khái niệm và các mối quan hệ của họ.
Mô hình khái niệm là bước khởi đầu quan trọng trước khi tạo sơ đồ UML, giúp người dùng nắm bắt các thực thể trong thế giới thực và mối quan hệ giữa chúng.
UML là công cụ quan trọng trong việc mô tả các hệ thống thời gian thực, vì vậy việc xây dựng một mô hình khái niệm là cần thiết và nên được thực hiện theo từng bước Để làm chủ mô hình khái niệm của UML, người học cần tập trung vào ba yếu tố chính.
Các quy tắc để kết nối các khối xây dựng
Các cơ chế chung của UML
Khái niệm hướng đối tượng
UML có thể được mô tả như là sự kế thừa của việc phân tích và thiết kế hướng đối tượng (OO).
Một đối tượng là thực thể chứa dữ liệu và các phương thức kiểm soát dữ liệu, thể hiện trạng thái của nó Lớp mô tả đối tượng và tạo thành hệ thống phân cấp, cho phép mô hình hóa các hệ thống thế giới thực thông qua thừa kế Các lớp có thể liên kết theo nhiều cách khác nhau tùy theo yêu cầu Các khái niệm cơ bản như trừu tượng, đóng gói, thừa kế và đa hình đều có thể được biểu diễn bằng UML.
UML là công cụ mạnh mẽ để thể hiện mọi khái niệm trong phân tích và thiết kế hướng đối tượng Các biểu đồ UML đóng vai trò là hình ảnh minh họa cho các khái niệm này, giúp dễ dàng hiểu và áp dụng trong quy trình phát triển phần mềm.
Do đó, trước khi học UML, điều quan trọng là phải hiểu khái niệm OO một cách chi tiết.
Dưới đây là một số khái niệm cơ bản của thế giới hướng đối tượng
- Đối tượng - Đối tượng đại diện cho một thực thể và khối xây dựng cơ bản.
- Lớp - Class là bản in của một đối tượng.
- Trừ tượng – Trừu tượng đại diện cho hành vi của một thực thể thế giới thực.
- Đóng gói - Tóm lược là cơ chế ràng buộc dữ liệu với nhau và giấu chúng khỏi thế giới bên ngoài.
- Thừa kế - Thừa kế là cơ chế tạo ra các lớp mới từ những lớp hiện có.
- Đa hình - Nó xác định cơ chế tồn tại dưới các hình thức khác nhau.
Phân tích và Thiết kế OO
OO được định nghĩa là một cuộc điều tra, tập trung vào việc nghiên cứu các đối tượng cụ thể Thiết kế trong bối cảnh này có nghĩa là hợp tác chặt chẽ với những đối tượng đã được xác định.
Hiểu rõ các khái niệm phân tích và thiết kế hướng đối tượng (OO) là rất quan trọng Mục tiêu chính của phân tích OO là xác định các đối tượng trong hệ thống được thiết kế, đồng thời cũng áp dụng cho các hệ thống hiện có.
Để phân tích hiệu quả, chúng ta cần bắt đầu bằng cách xác định các đối tượng liên quan Sau khi các đối tượng được xác định, chúng ta sẽ xác định các mối quan hệ giữa chúng, và cuối cùng là tiến hành thiết kế sản phẩm.
Mục đích của phân tích OO và thiết kế có thể mô tả như là
- Xác định các đối tượng của một hệ thống.
- Xác định mối quan hệ của họ.
- Làm một thiết kế, có thể được chuyển đổi sang các file thực thi sử dụng các ngôn ngữ OO.
Có ba bước cơ bản mà các khái niệm OO được áp dụng và thực hiện Các bước có thể được định nghĩa là
OO Analysis → OO Design → OO implementation using OO languages
Ba điểm trên có thể được mô tả chi tiết như là
THIẾT KẾ BIỂU ĐỒ
Biểu đồ lớp
Biểu đồ lớp thể hiện cấu trúc tĩnh của các lớp trong hệ thống, đại diện cho các "vật" được xử lý Các lớp có thể có mối quan hệ như liên kết, phụ thuộc, chuyên biệt hóa, và đóng gói, tất cả đều được thể hiện trong biểu đồ Cấu trúc bên trong của các lớp bao gồm thuộc tính và thủ tục Biểu đồ này được coi là tĩnh và có hiệu lực trong suốt vòng đời của hệ thống.
Hệ thống thường bao gồm nhiều biểu đồ lớp, nhưng không phải tất cả đều được tổng hợp thành một biểu đồ lớp duy nhất Một lớp có thể tham gia vào nhiều biểu đồ lớp khác nhau Thông tin chi tiết về biểu đồ lớp sẽ được trình bày trong chương tiếp theo.
Hình 3.3 - Biểu đồ lớp cho một giao dịch Tài chính
3.1.1 Biểu đồ lớp ở dạng tổng quát
Ví dụ: Xây dựng biểu đồ lớp cho hệ thống bán hàng
2 Xác định các môi quan hệ giữa các lớp
Có bao nhiêu cách xác định các lớp:
(i) Dựa vào văn bản, kịch bản mô tả bài toán: các danh từ có thể là các đại biểu của lớp.
(ii) Dựa vào danh sách phân loại các phạm trù khái niệm.
(iii) Dựa vào kinh nghiệm và kiến thức của người phân tích,
(iv) Dựa vào hồ sơ tài liệu những hệ thống có liên quan,
(v) Dựa vào ý kiến tham khảo với các chuyên gia hệ thống.
(i) Xác định các lớp đối tượng
+ Dựa vào văn bản mô tả bài toán để tìm các lớp
Trong các mô tả văn bản, danh từ có thể đại diện cho lớp hoặc thuộc tính của lớp Do đó, cần gạch chân tất cả các danh từ chung trong văn bản mô tả bài toán Ví dụ, hãy gạch chân những danh từ chung trong đoạn văn mô tả hệ HBH.
Công ty sở hữu nhiều điểm bán hàng đầu cuối tại các cửa hàng siêu thị, do đó hệ thống cần ghi nhận hoạt động bán hàng và xử lý thanh toán cho khách hàng mua lẻ Hệ thống còn hỗ trợ giám đốc theo dõi hoạt động kinh doanh, tự động kiểm kê hàng tồn kho và các mặt hàng bán chạy, từ đó hỗ trợ ra quyết định trong các hoạt động kinh doanh Mỗi điểm bán hàng đều được trang bị thiết bị phần cứng như máy tính và máy đọc mã vạch, cùng với phần mềm hệ thống được xây dựng để vận hành hiệu quả.
Lưu ý rằng không phải tất cả các danh từ được gạch chân trong phần mô tả bài toán đều đại diện cho lớp Chẳng hạn, các cụm từ như phần mềm hệ thống, máy tính và thiết bị phần cứng không phải là những thực thể chính mà chúng ta cần tập trung vào trong hệ thống HBH.
Một số cụm danh từ đồng nghĩa mô tả các thực thể có vai trò tương tự có thể được thay thế cho nhau Ví dụ, "hệ thống" và "hệ thống phần mềm" hay "hoạt động bán hàng" và "hoạt động kinh doanh" đều có ý nghĩa giống nhau Do đó, có thể sử dụng "HBH" thay cho "hệ thống" và "hệ thống phần mềm", trong khi "giao dịch bán hàng" (hay "phiên bán hàng") có thể thay thế cho "hoạt động bán hàng" và "hoạt động kinh doanh".
Dựa vào các danh từ và cụm danh từ đã được gạch chân, kết hợp với kinh nghiệm, trình độ và kiến thức cá nhân, chúng ta cần loại bỏ những mục không phải là đại biểu của lớp Danh sách đại biểu có thể được xác định từ hệ thống HBH của lớp.
HBH: đại diện cho hệ thống phần mềm, hệ thống,
CuaHang (cửa hàng): điểm bán hàng đầu cuối, cửa hàng siêu thị, v.v
PhienBanHang (phiên bán hàng): đại diện cho hoạt động bán hàng, hoạt động kinh doanh,
ThanhToan (thanh toán): đại diện cho công việc thanh toán, trả tiền
KhachHang (khách hàng): cho khách hàng, người mua hàng,
NguoiQL (Người quản lý): đại diện cho giám đốc Công ty, cửa hàng trưởng, MatHang (Mặt hàng): đại diện cho mặt hàng, sản phẩm, v.v.
(ii) Xác định các lớp đối tượng (TT)
+ Dựa vào kịch bản mô tả hoạt động của từng UC “Ban hang” để tìm các lớp
(iii) Ngoài ra, ta còn có thể dựa vào các câu hỏi sau để tìm ra các lớp:
• Những thông tin nào cần phân tích, lưu trữ?
• Những hệ thống ngoài nào cần thiết cho hệ thống và ngược lại?
• Những mẫu (pattern), thư viện lớp, thành phần nào được sử dụng trong hệ thống?
• Hệ thống quản lý những thiết bị ngoại vi nào?
• Vai trò của các tác nhân đối với hệ thống là gì?
Những câu trả lời cho các câu hỏi trên có thể là đại biểu của lớp.
Bằng những cách nêu trên, hệ thống HBH có những lớp sau:
HBH (POST - Point Of Sale Terminal) DongBanHang (SaleLineItem)
MatHang (Items) ThanhToan (Thanh toán – Payment)
CuaHang (Store) MoTaMatHang (Product Specification)
DanhMucMatHang (Product Catalog) NguoiBan (Cashier)
2 Xác định các mối quan hệ kết hợp
2.1 Mối quan hệ kết hợp giữa các lớp đối tượng là cần thiết để biết về những thông tin liên quan đến các lớp đó Nghĩa là dựa vào nguyên lý “Cần để biết”.
2.2 Sự liên kết quan trọng giữa hai đối tượng phải thể hiện được vai trò của sự cộng tác hay sự tương tác giữa các đối tượng đó.
Dựa vào nguyên lý “Cần để biết” trong việc “Mua hàng bằng tiền mặt”, chúng ta nhận thấy có những mối quan hệ quan trọng Nguyên lý này giúp người tiêu dùng hiểu rõ hơn về quy trình thanh toán, từ đó tăng cường sự tự tin khi thực hiện giao dịch Việc nắm vững thông tin về sản phẩm và giá cả là yếu tố then chốt để đưa ra quyết định mua sắm hợp lý.
+ HBH Xử-lý PhienBanHang để biết về lần bán hàng hiện thời, biết tổng số tiền khách hàng phải trả và để in phiếu bán hàng giao cho khách.
PhienBanHang Được-trả-tiền-bởi ThanhToan cho phép kiểm tra tình trạng thanh toán của hàng hóa đã bán Nó liên quan đến số tiền khách hàng thanh toán, đảm bảo rằng hệ thống có thể hoàn trả tiền thừa và in phiếu bán hàng một cách chính xác.
+ DanhMucMatHang Ghi-lại MoTaMatHang để tìm các thông tin mô tả về các mặt hàng như: chủng loại, giá cả, chất lượng, v.v khi biết mã sản phẩm.
Các lớp trong HBH có các quan hệ như sau:
3.1.2 Biểu đồ lớp ở dạng chi tiết a Các thành phần cơ sở
Mục đích của sơ đồ lớp là để thể hiện các kiểu thành phần được mô hình hóa trong hệ thống Trong hầu hết các mô hình UML, các thành phần này bao gồm:
• lớp giao diện kiểu dữ liệu thành phần.
UML sử dụng thuật ngữ "phân loại" để chỉ các thành phần trong mô hình, tương tự như khái niệm lớp nhưng bao quát hơn Phân loại đề cập đến ba kiểu thành phần khác nhau, cho phép người dùng hiểu rõ hơn về cấu trúc và chức năng trong thiết kế hệ thống.
Biểu diễn UML của một lớp được thể hiện dưới dạng hình chữ nhật chia thành ba ngăn dọc Ngăn trên cùng hiển thị tên lớp, ngăn giữa liệt kê các thuộc tính lớp, và ngăn dưới cùng mô tả các hoạt động của lớp Khi vẽ sơ đồ lớp, ngăn trên cùng là bắt buộc, trong khi hai ngăn dưới có thể không cần thiết trong các sơ đồ mức cao chỉ nhằm thể hiện mối quan hệ giữa các phân loại Ví dụ, hình ảnh mô tả một chuyến bay của hãng hàng không được mô hình hóa như lớp UML với tên là Flight, có ba thuộc tính: flightNumber, departureTime và flightDuration, cùng hai hoạt động: delayFlight và getArrivalTime.
Hình 1: Sơ đồ lớp cho lớp Flight
Danh sách các thuộc tính của lớp
Phần thuộc tính của lớp, nằm ở giữa, liệt kê từng thuộc tính trên một dòng riêng biệt Mặc dù phần này là tùy chọn, khi được sử dụng, nó sẽ hiển thị mỗi thuộc tính của lớp dưới dạng danh sách Định dạng của mỗi dòng là: tên thuộc tính : loại thuộc tính, ví dụ: flightNumber : Integer.
Tiếp tục với ví dụ lớp Flight, chúng ta có thể mô tả các thuộc tính của lớp với thông tin về kiểu thuộc tính, như trong bảng 1.
Bảng 1: Các tên của thuộc tính của lớp Flight cùng với các kiểu thuộc tính kết hợp của chúng
Tên thuộc tính Kiểu thuộc tính flightNumber Integer departureTime Date (Ngày) flightDuration Minutes (Phút)
Trong sơ đồ lớp nghiệp vụ, các kiểu thuộc tính thường phản ánh các đơn vị có ý nghĩa đối với người đọc, như phút hay đô la Tuy nhiên, để tạo mã từ sơ đồ lớp, cần sử dụng các lớp với kiểu thuộc tính giới hạn trong các kiểu do ngôn ngữ lập trình cung cấp hoặc các kiểu có trong mô hình hệ thống Đôi khi, cần chỉ ra rằng một thuộc tính cụ thể có giá trị mặc định, chẳng hạn như trong ứng dụng tài khoản ngân hàng, tài khoản mới sẽ có số dư bằng không Đặc tả UML cho phép xác định giá trị mặc định trong danh sách thuộc tính bằng cách sử dụng cú pháp: tên : kiểu thuộc tính = giá trị mặc định.
Biểu đồ đối tượng (Object Diagram)
Biểu đồ đối tượng là một phiên bản của biểu đồ lớp, sử dụng các ký hiệu tương tự nhưng khác biệt ở chỗ nó chỉ ra một loạt các đối tượng thực thể của lớp thay vì các lớp Đây là một ví dụ thực tế của biểu đồ lớp, minh họa trạng thái của hệ thống tại một thời điểm cụ thể Trong biểu đồ đối tượng, tên của các đối tượng được gạch dưới và tất cả các thực thể trong mối quan hệ đều được chỉ ra, giúp người dùng dễ dàng hình dung cấu trúc và mối quan hệ giữa các đối tượng trong hệ thống.
Biểu đồ đối tượng không quan trọng bằng biểu đồ lớp, nhưng chúng có thể giúp hình dung một biểu đồ lớp phức tạp bằng cách chỉ ra các thực thể cụ thể và mối quan hệ giữa chúng Thực tế, biểu đồ đối tượng thường được sử dụng như một phần trong biểu đồ cộng tác, thể hiện hành vi động giữa nhiều đối tượng.
Hình 3.4 - Biểu đồ lớp và biểu đồ đối tượng thể hiện của lớp
Biểu đồ ca sử dụng (USECASE)
Use Case được thể hiện trong ngôn ngữ UML thông qua biểu đồ Use Case (Use Case Diagram) Mô hình Use Case có thể được phân chia thành nhiều biểu đồ khác nhau Mỗi biểu đồ Use Case bao gồm các phần tử mô hình đại diện cho hệ thống, tác nhân và các Use Case, đồng thời chỉ ra các mối quan hệ giữa các Use Case.
Lời mô tả Use Case thường được trình bày dưới dạng văn bản, được xem là thuộc tính "văn bản" trong UML, chứa đựng thông tin quan trọng về yêu cầu và chức năng Thay vì chỉ sử dụng văn bản, bạn có thể sử dụng biểu đồ hoạt động để mô tả Use Case Tuy nhiên, cần lưu ý rằng mô tả Use Case cần phải rõ ràng và dễ hiểu cho người sử dụng, vì các cấu trúc phức tạp như biểu đồ hoạt động có thể gây khó khăn cho những người không quen thuộc.
Tóm tắt: Một biểu đồ Use Case thể hiện:
Ví dụ biểu đồ Use Case trong UML:
- Một ví dụ biểu đồ Use case trong UML
- Hệ thống được thể hiện qua hình chữ nhật với tên hệ thống ở bên trên
- Tác nhân được thể hiện qua kí hiệu hình nhân
- Use Case được thể hiện qua hình ellipse
Khi nhận diện tác nhân, chúng ta cần lọc ra các thực thể quan trọng liên quan đến việc sử dụng và tương tác với hệ thống Việc đặt mình vào vị trí của tác nhân giúp chúng ta hiểu rõ hơn về các yêu cầu và đòi hỏi của họ đối với hệ thống, từ đó xác định các Use Case cần thiết Để nhận diện tác nhân, có thể trả lời một số câu hỏi cụ thể liên quan đến nhu cầu và mục tiêu của họ.
- Ai sẽ sử dụng những chức năng chính của hệ thống (tác nhân chính)?
- Ai sẽ cần sự hỗ trợ của hệ thống để thực hiện những tác vụ hàng ngày của họ?
- Ai sẽ cần bảo trì, quản trị và đảm bảo cho hệ thống hoạt động (tác nhân phụ)?
- Hệ thống sẽ phải xử lý và làm việc với những trang thiết bị phần cứng nào?
Hệ thống cần tương tác với các hệ thống khác, được chia thành hai nhóm: nhóm kích hoạt mối quan hệ và nhóm mà hệ thống cần thiết lập quan hệ Khái niệm hệ thống không chỉ bao gồm các hệ thống máy tính khác mà còn cả các ứng dụng trên cùng một máy tính mà hệ thống này sẽ hoạt động.
- Ai hay cái gì quan tâm đến kết quả (giá trị) mà hệ thống sẽ sản sinh ra?
Khi xác định người sử dụng hệ thống, không chỉ chú ý đến những người ngồi trước màn hình máy tính, mà bất kỳ ai hoặc bất kỳ vật nào tương tác với hệ thống đều có thể là người sử dụng Mô hình hóa Use Case nhằm phản ánh doanh nghiệp, do đó tác nhân thường là khách hàng, không chỉ là những người thao tác trực tiếp với máy tính Để nhận diện các tác nhân khác nhau, cần nghiên cứu người sử dụng hiện tại của hệ thống, tìm hiểu vai trò của họ trong công việc hàng ngày và nhận ra rằng cùng một người có thể đảm nhận nhiều vai trò khác nhau tùy thuộc vào chức năng của hệ thống được sử dụng.
Tác nhân là một vai trò trong hệ thống, không phải là một thực thể riêng lẻ Để minh chứng cho sự tồn tại của tác nhân, có thể đưa ra ví dụ về một số thực thể liên quan Mỗi tác nhân cần có sự liên kết với ít nhất một hoặc nhiều Use Case, mặc dù không phải tất cả tác nhân đều kích hoạt Use Case Tuy nhiên, mỗi tác nhân sẽ giao tiếp với ít nhất một Use Case tại một thời điểm nào đó Quan trọng là tên của tác nhân phải phản ánh đúng vai trò của nó trong hệ thống.
Quá trình xác định các Use Case bắt đầu từ những tác nhân đã được liệt kê trước đó Đối với mỗi tác nhân, cần đặt ra các câu hỏi như: Tác nhân này cần những chức năng nào từ hệ thống? Hành động chính mà tác nhân thực hiện là gì?
Ví dụ cho một giao dịch rút tiền bên máy ATM trong một nhà băng lẻ, các hành động chính của khách hàng (tác nhân) có thể là:
- Đút thẻ vào máy ATM
- Nhập số tiền mặt muốn rút ra
- Yêu cầu về loại tiền
- Nhặt tiền ra từ máy
Rút thẻ và tờ in kết quả giao dịch là quy trình quan trọng trong việc quản lý thông tin Tác nhân cần xác định xem có cần đọc, tạo, hủy bỏ, sửa chữa hay lưu trữ thông tin nào trong hệ thống hay không Việc này đảm bảo tính chính xác và bảo mật cho dữ liệu giao dịch.
- Nhân viên nhà băng liệu có quyền truy xuất hay thay đổi mức tiền lãi?
Khách hàng có quyền thay đổi mật khẩu của mình Đồng thời, tác nhân cần thông báo cho hệ thống về các sự kiện quan trọng, vì những sự kiện này sẽ đại diện cho các chức năng cụ thể trong hệ thống.
- Khách hàng kết thúc tài khoản, nhân viên cung cấp những thông tin này cho hệ thống.
Có một chương trình đầu tư mới mà nhân viên ngân hàng sẽ phải nhập các chi tiết vào hệ thống
- Trong tài khoản còn quá ít tiền.
Trong thời gian gần đây, tiền lương đã không được chuyển về tài khoản trong hai kỳ liên tiếp Để cải thiện tình hình, công việc hàng ngày của nhân viên có thể được tối ưu hóa thông qua việc áp dụng các chức năng mới trong hệ thống, đặc biệt là những chức năng chưa được tự động hóa Điều này sẽ giúp nâng cao hiệu quả làm việc và giảm bớt gánh nặng cho các tác nhân.
Use Case có thể được gây ra bởi các sự kiện nào khác?
Sự kiện thời gian: Cuối tháng, hết hạn đầu tư.
Sự kiện bình thường của hệ thống: Tự động chuyển tiền theo các lệnh xác định trước.
Các sự kiện bất bình thường: Hợp đồng đầu tư kết thúc trước thời hạn.
- Hệ thống cần những thông tin đầu vào/đầu ra nào? Những thông tin đầu vào/đầu ra đó từ đâu tới và sẽ đi đâu?
Khó khăn và thiếu hụt trong hệ thống hiện tại chủ yếu nằm ở sự phân chia giữa thủ công và tự động hóa Đối với nhóm câu hỏi cuối, không có nghĩa là các Use Case không có tác nhân; thực tế, tác nhân chỉ được nhận diện khi chúng ta xác định các Use Case và từ đó xác định tác nhân dựa trên những Use Case này Cần nhớ rằng mỗi Use Case phải luôn được liên kết với ít nhất một tác nhân.
-Ví dụ tìm Use Case:
Nhà băng ABC đưa ra các yêu cầu sau:
Khách hàng có thể thực hiện các giao dịch như gửi tiền, rút tiền hoặc kiểm tra số dư tài khoản qua máy ATM Sau khi thực hiện các giao dịch này, cần ghi lại kết quả và cung cấp cho khách hàng một bản sao để họ có thể theo dõi các chuyển động tài chính của mình.
Trong quá trình quan sát các chức năng cơ bản và các thành phần tham gia, hai tác nhân nổi bật nhất chính là khách hàng và nhân viên thu ngân.
Qua đó, có thể nhân dạng các Use Case sau:
- Kiểm tra mức tiền trong tài khoản
- Thực hiện các chuyển dịch nội bộ hệ thống
- In kết quả các chuyển dịch đã thực hiện.
Hình 4.3 – Các Use case trong hệ thống ATM
Use Case gửi tiền và rút tiền phụ thuộc vào các giao dịch nội bộ của hệ thống, và việc thực hiện này còn liên quan đến chức năng in ra các công việc đã hoàn thành Đồng thời, việc kiểm tra số dư tài khoản được xem là một Use Case độc lập, không bị ảnh hưởng bởi các Use Case khác.
- CÁC BIẾN THỂ (VARIATIONS) TRONG MỘT USE CASE
Mỗi Use Case sẽ có một dòng hành động chính (Basic Course) Đó là tiến trình bình thường hay tiến trình mong đợi đối với Use Case này.
Ngoài ra, có thể còn có một hay nhiều dòng hành động thay thế (Alternative) khác. Chúng có thể được chia làm hai nhóm chính:
- Thay thế bình thường (Normal Alternative)
- Điều kiện gây lỗi (Error Condidtions)
Những gì mang tính bình thường hơn trong Use Case được gọi là Thay thế bình thường.
Có thể miêu tả các dòng hành động thay thế bằng từ ngữ (xem phần tài liệu Use Case ).
Ví dụ một khách hàng có thể chọn các loại giao dịch sau của ATM:
Biểu đồ tuần tự (Sequence Diagram)
3.4.1 Giới thiệu biểu đồ tuần tự
Biểu đồ tuần tự là công cụ hữu ích để xác định trình tự diễn ra các sự kiện trong một nhóm đối tượng Nó mô tả chi tiết quá trình gửi và nhận thông điệp giữa các đối tượng, đồng thời nhấn mạnh sự quan trọng của thời gian trong việc gửi và nhận các thông điệp này.
3.4.2 Các thành phần của biểu đồ tuần tự
Đối tượng (object or class): biểu diễn bằng các hình chữ nhật
Đường đời đối tượng (Lifelines): biểu diễn bằng các đường gạch rời thẳng đứng bên dưới các đối tượng
Thông điệp (Message): biểu diễn bằng các đường mũi tên
Thông điệp được dùng để giao tiếp giữa các đối tượng và lớp Có nhiều loại thông điệp được định nghĩa ở phần 1.3
Xử lí bên trong đối tượng (biểu diễn bằng các đoạn hình chữ nhật rỗng nối với các đường đời đối tượng)
3.4.3 Các loại thông điệp trong biểu đồ tuần tự
Thông điệp đồng bộ (Synchronous Message)
Thông điệp đồng bộ cần có một request trước hành động tiếp theo.
Thông điệp không đồng bộ (Asynchronous Message)
Thông điệp không đồng bộ không cần có một request trước hành động tiếp theo.
Thông điệp chính mình (Self Message)
Là thông điệp mà đối tượng gửi cho chính nó để thực hiện các hàm nội tại.
Thông điệp trả lời hoặc trả về (Reply or Return Message)
Thông điệp phản hồi là kết quả trả lời khi có yêu cầu hoặc sau khi xác minh tính chính xác của một điều kiện nào đó Ví dụ, các thông điệp này thường là các tin nhắn trả về với trạng thái thành công (success) hoặc thất bại (fail).
Thông điệp tạo mới (Create Message)
Là thông điệp được trả về khi tạo mới một đối tượng.
Thông điệp xóa (Delete Message) Là thông điệp được trả về khi xóa một đối tượng.
VD1: Sơ đồ tuần tự của chức năng đăng nhập.Xem xét đối tượng tài khoản sau đây
Trong sơ đồ trên có 3 đối tượng là : người dùng, hệ thống và tài khoản Luồng xử lí của chức năng đăng nhập có thể diễn giải như sau.
1 Người dùng gửi yêu cầu đăng nhập đến hệ thống.
2 Hệ thống yêu cầu người dùng nhập email và mật khẩu.
3 Người dùng nhập email và mật khẩu.
4 Hệ thống gửi email và mật khẩu của người dùng để kiểm tra.
5 Tài khỏan kiểm tra thông tin email và password có đúng hay không.
6 Tài khoản trả về kết qủa kiểm tra cho hệ thống.
7 Hệ thống trả về thông báo cho người dùng.
Biểu đồ trạng thái (State Diagram)
3.5.1 Giới thiệu về biểu đồ trạng thái
Biểu đồ trạng thái mô tả các trạng thái khả thi và sự chuyển đổi giữa chúng khi có sự kiện từ một đối tượng Đối với những đối tượng có nhiều trạng thái, biểu đồ trạng thái là công cụ hiệu quả giúp chúng ta hiểu rõ hơn về hệ thống.
3.5.2 Các thành phần của biểu đồ trạng thái
Trạng thái bắt đầu: (Initial State)
Trạng thái kết thúc: (Final State)
Trong biểu đồ, đường mũi tên chỉ ra sự biến đổi từ một trạng thái sang trạng thái khác.
Sự kiện (Event) hoặc Chuyển đổi (Transition)
Trạng thái đối tượng (State)
Biểu đồ trạng thái thể hiện lớp Sach trong một hệ thống quản lí thư viện điện tử:
Biểu đồ trạng thái của lớp Sach bao gồm năm trạng thái chính: sẵn sàng cho mượn, đã có người mượn, hết hạn lưu hành, đã mượn, và mất Ngoài ra, còn có hai trạng thái phụ là trạng thái khởi tạo và trạng thái kết thúc.
1 Sách khởi tạo ở trạng thái "sẵn sàng cho mượn"
2 Sách chuyển từ trạng thái "sẵn sàng cho mượn" sang trạng thái "Đã mượn" khi có người mượn sách.
3 Sách chuyển từ trạng thái "sẵn sàng cho mượn" sang trạng thái "Hết hạn lưu hành" khi có quyết định hết hạn lưu hành.
4 Sách "đã có người mượn" chuyển sang trạng thái "Hết hạn lưu hành" khi có quyết định hết hạn lưu hành.
5 Sách chuyển từ trạng thái "hết hạn lưu hành" sang trạng thái "lưu trữ" khi có quyết định lưu trữ
6 Sách chuyển từ trạng thái "đã có người mượn" sang trạng thái "mất" khi làm mất.
7 Sách chuyển từ trạng thái "đã có người mượn" sang trạng thái "sẵn sàng cho mượn" khi trả sách.
Biểu đồ hoạt động (Active Diagram)
3.6.1 Giới thiệu biểu đồ hoạt động
Biểu đồ hoạt động là công cụ mô tả các bước thực hiện, hành động, nút quyết định và điều kiện rẽ nhánh để điều khiển luồng thực hiện của hệ thống Đặc biệt, nó là lựa chọn tối ưu cho các luồng thực thi có nhiều tiến trình chạy song song Mặc dù biểu đồ hoạt động và biểu đồ trạng thái có nhiều ký hiệu tương tự, nhưng cần phân biệt rõ ràng giữa hai loại này Biểu đồ hoạt động tập trung vào việc mô tả các hoạt động và kết quả từ việc thay đổi trạng thái của đối tượng, trong khi biểu đồ trạng thái chỉ thể hiện tất cả các trạng thái của một đối tượng và các sự kiện dẫn đến sự thay đổi giữa các trạng thái đó.
3.6.2 Các thành phần của biểu đồ hoạt động
Trạng thái khởi tạo hoặc điểm bắt đầu (Initial State or Start Point)
Hoạt động hoặc trạng thái hoạt động (Activity or Action State)
Hoạt động và sự chuyển đổi hoạt động được ký hiệu và cách sử dụng hoàn toàn giống như trạng thái trong biểu đồ trạng thái đã nêu ở trên.
Nút quyết định và rẽ nhánh
Nút rẽ nhánh trong biểu đồ hoạt động được kí hiệu bằng hình thoi màu trắng.
Thanh tương tranh hay thanh đồng bộ
Có thể có nhiều luồng hành động được bắt đầu thực hiện hay kết thúc đồng thời trong hệ thống.
Thanh đồng bộ kết hợp:
Thanh đồng bộ chia nhánh:
Cạnh gián đoạn (Interrupting Edge)
Luồng hoạt động (Action Folow)
Phân làn trong biểu đồ được thể hiện bằng các đường nét đứt thẳng đứng, giúp phân biệt các đối tượng Ký hiệu này thường được áp dụng để làm rõ luồng hoạt động của từng đối tượng riêng biệt.
Thời gian sự kiện (Time Event)
Gửi và nhận tín hiệu (Sent and Received Signals)
Trạng thái kết thúc hoặc điểm cuối (Final State or End Point)
VD1:Biểu đồ hoạt động rút tiền tại cây ATM:
Bài viết mô tả ba hoạt động diễn ra đồng thời: xác nhận thẻ, xác nhận mã số PIN và xác nhận số tiền rút Việc sử dụng biểu đồ hoạt động là cần thiết để minh họa rõ ràng các hoạt động song song này.
VD2: Thêm một ví dụ nữa để chúng ta hiểu hơn về biểu đồ hoạt động với các hành động được phân làn.
Biểu đồ hoạt động thể hiện một qúa trình đặt hàng.
Biểu đồ thành phần
Biểu đồ thành phần (Component Diagram) mô tả các thành phần và sự phụ thuộc của chúng trong hệ thống, bao gồm mã nguồn và các chương trình cài đặt lớp Trong C++, mỗi tệp cpp và h được coi là một thành phần Trước khi phát sinh mã chương trình, cần ánh xạ từng tệp vào thành phần tương ứng, với mỗi lớp thường được ánh xạ vào hai tệp (.cpp và h).
Thành phần mã nhị phân là mã trình nhị phân được chuyển đổi từ mã chương trình nguồn, bao gồm các tệp mã đích (.obj), tệp thư viện tĩnh (.lib) và tệp thư viện động (.dll) Những thành phần này được sử dụng để liên kết hoặc thực thi chương trình, đặc biệt là đối với thư viện động.
Thành phần thực thi, thường là các tệp chương trình có đuôi exe, là kết quả của quá trình liên kết các thành phần nhị phân trong lập trình.
Biểu đồ thành phần giúp các nhà phát triển hệ thống nhận biết các thư viện mã trình có sẵn và các tệp thực thi (.exe) trong quá trình biên dịch và liên kết.
Trong các thành phần, chỉ có một loại quan hệ phụ thuộc được thể hiện bằng đường mũi tên đứt nét Kết nối này chỉ ra rằng thành phần phụ thuộc cần phải được dịch chuyển sau thành phần chính.
Nên tránh phụ thuộc vòng tròn trong biểu đồ thành phần.
Biểu đồ thành phần mô tả sự phụ thuộc giữa các thành phần của hệ thống.
Sự phụ thuộc của các thành phần trong biểu đồ thành phần.Trong UML (và Rose) có một số biểu tượng biểu diễn cho các thành phần, đó là:
Thành phần: biểu tượng thành phần (hình 1) được sử dụng để biểu diễn module chương trình có các giao diện Trong đặc tả có xác định kiểu Stereotype
ActiveX, Applet, DLL và exe là những thành phần quan trọng trong lập trình Biểu tượng thành phần cho đặc tả chương trình con được thể hiện trong hình 2b, trong khi đặc tả dạng cài đặt của chương trình con được minh họa ở hình 2c Đáng lưu ý, chương trình con này không chứa các định nghĩa lớp.
Chương trình chính là biểu tượng thành phần chứa điểm vào của chương trình, ví dụ trong C/C++ là tệp chứa hàm main() Đặc tả và thân của gói được thể hiện qua tệp header, trong đó chứa thông tin về các hàm thành phần của lớp, chẳng hạn như tệp h trong C/C++ định nghĩa các hàm prototype Thân gói chứa mã lệnh của các hàm thành phần, được lưu trữ trong tệp cpp Cuối cùng, các biểu tượng cho phần đặc tả và nội dung của những nhiệm vụ độc lập được minh họa qua các hình ảnh tương ứng.
Tương tự như các phần tử khác trong UML, đối với các thành phần cũng có thể bổ sung một số đặc tả chi tiết:
Stereotype là mẫu rập khuôn dùng để phân nhóm các thành phần, bao gồm nhiều lựa chọn như: không có, đặc tả chương trình con, chương trình chính, đặc tả gói, nội dung gói, đặc tả nhiệm vụ, nội dung công việc, ActiveX, Applet, ứng dụng, và nhiều loại khác.
+ Ngôn ngữ: Rose cho phép lựa chọn ngôn ngữ lập trình cho từng thành phần, như C++, Java, Visual Basic, Oracle 8, v.v.
+ Khai báo: phụ thuộc được gộp vào mã chương trình cho mỗi thành phần
Lệnh #include của C++ được xem như là lệnh khai báo.
Trước khi mã chương trình được tạo ra, lớp cần được ánh xạ vào thành phần, giúp Rose xác định tệp mà mã lớp sẽ được lưu trữ Một thành phần có thể ánh xạ một hoặc nhiều lớp.
Biểu đồ thành phần là tập hợp các biểu tượng đại diện cho các thành phần vật lý trong một hệ thống Mục đích chính của biểu đồ này là cung cấp cho các nhà thiết kế và phát triển hệ thống một cái nhìn tổng quát về các thành phần cấu thành nên hệ thống.
Hỏi: Khi tạo dựng mô hình, cần sử dụng các khái niệm của chính phạm vi vấn đề để mô hình dễ hiểu và dễ giao tiếp. Đáp: Đúng
Các lớp không chỉ thể hiện cấu trúc thông tin mà còn mô tả hành vi, vì vậy quan niệm cho rằng chúng chỉ có chức năng này là sai lầm.
Hỏi: Các khái niệm then chốt thường sẽ trở thành các lớp trong mô hình phân tích? Đáp: Đúng
Hỏi: Thường các danh từ trong các lời phát biểu bài toán sẽ là ứng cử viên để chuyển thành lớp và đối tượng? Đáp: Đúng
Quan hệ kết hợp (Association) giữa các lớp định nghĩa các mối liên quan có thể tồn tại giữa các đối tượng Cụ thể, đây là sự nối kết giữa các lớp, thể hiện mối liên hệ giữa các đối tượng thuộc các lớp này.
Hỏi: Kết tập biểu thị rằng quan hệ giữa các lớp dựa trên nền tảng của nguyên tắc
Một tổng thể được hình thành từ các bộ phận khác nhau Điều này đúng vì nó thể hiện việc tạo ra một thực thể mới thông qua việc kết hợp các thực thể đã tồn tại.
Khái quát hoá không được sử dụng để tạo ra các lớp con; thay vào đó, nó là quá trình bắt đầu từ một lớp chuyên biệt và dần dần nâng cao tính khái quát của lớp đó, hướng tới lớp cha.
Chuyên biệt hoá là quá trình tinh chỉnh một lớp thành những lớp chuyên biệt hơn, thường được gọi là lớp con, nhằm bổ sung thêm chi tiết và đặc tả cho kết quả.
