Giới thiệu
Thách thức lớn nhất của loài người trong thế kỷ 21 là sự phức tạp và hỗn độn trong nhiều lĩnh vực Khoa học tính toán và tin học sẽ là chìa khóa để nâng cao trí tuệ con người, giúp giải quyết các vấn đề phức tạp trong cuộc sống Nền kinh tế hiện đại cần chuyển sang nền kinh tế tri thức, yêu cầu sự đổi mới liên tục thay vì dựa vào tài nguyên vật chất Để kiểm soát độ phức tạp này, cần áp dụng các phương pháp khoa học phù hợp với quy luật xã hội và tự nhiên Việc nghiên cứu từng bộ phận của hệ thống là cần thiết để mô hình hóa và hiểu rõ quá trình hình thành của chúng Như Pascal đã nói, "Không thể hiểu được bộ phận nếu không hiểu toàn thể và không thể hiểu toàn thể nếu không hiểu được từng bộ phận." Do đó, nhiệm vụ của các ngành khoa học là nghiên cứu các quy luật tự nhiên và hành vi của hệ thống, từ đó đề xuất các phương pháp hiệu quả để giải quyết vấn đề trong hoạt động của con người.
Nhiệm vụ của công nghệ thông tin, đặc biệt là công nghệ phần mềm, là nghiên cứu các mô hình, phương pháp và công cụ để phát triển hệ thống phần mềm chất lượng cao trong điều kiện tài nguyên hạn chế, đáp ứng nhu cầu thay đổi của khách hàng và giải quyết các vấn đề phức tạp Trước những năm 60, quy trình phát triển phần mềm chưa có phương pháp rõ ràng, dẫn đến việc xây dựng hệ thống phần mềm một cách tuỳ tiện dựa trên sở thích và kinh nghiệm cá nhân Từ những năm 70 đến nay, nhiều mô hình và phương pháp phát triển phần mềm đã ra đời, mỗi phương pháp có ưu, nhược điểm riêng, được ưa chuộng ở những lĩnh vực khác nhau, nhưng cũng gây ra sự không thống nhất và thiếu chuẩn hoá trong ngành.
Trải qua thời gian, một số phương pháp phát triển phần mềm đã chứng tỏ sự bền vững và được áp dụng rộng rãi Đặc biệt, các phương pháp có cấu trúc nổi bật với cách tiếp cận thống nhất, hướng thủ tục và tư duy từ trên xuống, mặc dù mỗi phương pháp chỉ tập trung vào một khía cạnh cụ thể của quá trình phát triển Do đó, trong các dự án phần mềm phức tạp, người ta thường kết hợp nhiều phương pháp khác nhau để bổ sung cho nhau Những phương pháp này vẫn còn hiệu quả cho các hệ thống có cấu trúc với dữ liệu đồng nhất Tuy nhiên, sự phong phú về phương pháp luận và sự đa dạng trong biểu diễn khái niệm đã tạo ra thách thức trong việc xây dựng một quy trình thống nhất cho phát triển phần mềm Hơn nữa, nhiều vấn đề phức tạp mới xuất hiện, yêu cầu khả năng tính toán lớn, xử lý phân tán, và quản lý nhiều loại dữ liệu khác nhau như dữ liệu đa phương tiện, âm thanh và hình ảnh.
Từ những năm 90, phương pháp hướng đối tượng đã trở thành một trào lưu mạnh mẽ trong phát triển phần mềm, thay thế cho các phương pháp cấu trúc truyền thống Phương pháp này tập trung vào các thực thể (đối tượng) và xây dựng lý thuyết cho các hệ thống tổng quát, xem hệ thống như một tập hợp các đối tượng tương tác qua việc truyền thông điệp để thực hiện nhiệm vụ Cách tiếp cận hướng đối tượng phù hợp với cách quan sát thế giới xung quanh, tạo ra công cụ hiệu quả cho việc phát triển hệ thống mở và dễ thay đổi, đáp ứng các tiêu chuẩn phần mềm hiện đại và giải quyết những vấn đề phức tạp của thế kỷ 21 Một khía cạnh quan trọng trong công nghệ phần mềm là các khái niệm mới của mô hình hệ thống hướng đối tượng, với quy trình phát triển có thể được đặc tả và thực hiện theo một hệ thống ký hiệu chuẩn, sử dụng ngôn ngữ mô hình hóa hợp nhất UML.
Language) [3, 10], được sự hỗ trợ của những phần mềm công cụ như Rational Rose
[17, 22] Những công cụ này hỗ trợ rất hiệu quả cho các giai đoạn phân tích, thiết kế và lập trình hướng đối tượng.
Giới thiệu về hệ thống phần mềm
Các đặc trưng của hệ thống
Hệ thống thông tin cũng giống như các hệ thống khác đều có những đặc trưng cơ bản như sau:
1 Mọi hệ thống đều có tính nhất thể hoá và đặc tính này được thể hiện thông qua:
Phạm vi và quy mô của hệ thống được xác định như một thể thống nhất, và hệ thống này sẽ không thay đổi trong những điều kiện nhất định Tuy nhiên, khi các điều kiện này không còn được đảm bảo, hệ thống sẽ cần phải biến đổi để thích ứng.
Tạo ra các đặc tính chung giúp thực hiện nhiệm vụ và đạt được mục tiêu chung mà từng bộ phận riêng lẻ không thể hoàn thành.
2 Trong sự hỗn độn, phức tạp của thế giới xung quanh, một hệ thống được tạo ra và phát triển thì phải có tính tổ chức, có thứ bậc Nghĩa là:
Mọi hệ thống đều là một phần của hệ thống lớn hơn trong một môi trường nhất định, đồng thời cũng bao gồm các hệ thống nhỏ hơn, tức là các thành phần bên trong nó.
Giữa các thành phần của một hệ thống có sự sắp xếp theo quan hệ thứ bậc hay một trình tự nhất định
3 Mọi hệ thống đều có cấu trúc: Chính cấu trúc của hệ thống quyết định cơ chế vận hành của hệ thống và mục tiêu mà nó cần đạt được Cấu trúc của hệ thống được thể hiện bởi:
Các phần tử được sắp xếp theo trật tự để cấu thành một hệ thống
Mối quan hệ giữa các thành phần liên quan chủ yếu đến loại hình, số lượng, chiều, cường độ, v.v
Hệ thống có cấu trúc chặt thường được gọi là hệ thống có cấu trúc, và cấu trúc này đóng vai trò quyết định tính chất cơ bản của hệ thống Chẳng hạn, kim cương và than đá đều được cấu tạo từ các phân tử carbon, nhưng do khác biệt về cấu trúc, kim cương trở nên vô cùng rắn chắc trong khi than đá lại không có tính chất này.
Sự thay đổi cấu trúc có thể tạo ra những đặc tính mới của hệ thống, dẫn đến những đột biến khi vượt qua ngưỡng nhất định, có thể gây ra sự phá vỡ hệ thống cũ Một ví dụ điển hình là công nghệ biến đổi gen, nơi cấu trúc của các tế bào sinh học được thay đổi Nguyên lý di truyền và biến đổi gen trong công nghệ sinh học hiện đang được nghiên cứu và ứng dụng trong lĩnh vực công nghệ thông tin.
4 Mọi hệ thống đều biến đổi theo thời gian và không gian:
Mỗi hệ thống đều có một vòng đời, từ khi ra đời cho đến khi bị loại bỏ Để tồn tại và phát triển, các hệ thống cần phải thay đổi phù hợp với điều kiện thực tế theo thời gian và không gian, tuân theo quy luật tiến hóa tự nhiên của Darwin Sự khác biệt chủ yếu giữa các hệ thống nằm ở tốc độ và khả năng nhận thức về sự thay đổi này.
Mọi sự thay đổi luôn có mối liên hệ ngược (feedback) trong hệ thống và chịu sự tác động của qui luật “nhân - quả”
Hệ thống phần mềm hiện nay được đánh giá dựa trên nhiều tiêu chí khác nhau, nhưng vẫn chưa có một hệ thống tiêu chí chuẩn mực cho tất cả các sản phẩm phần mềm Trong bài viết này, chúng ta sẽ tập trung vào những tính chất quan trọng nhất của các sản phẩm công nghệ phần mềm, bên cạnh những đặc điểm chung đã nêu.
Tính tiện dụng (usability) của sản phẩm là yếu tố quan trọng, yêu cầu sản phẩm phải dễ sử dụng và tiện lợi cho người dùng, giúp họ thực hiện công việc hiệu quả hơn Để đạt được điều này, phần mềm cần có giao diện thân thiện và phù hợp, đi kèm với tài liệu mô tả đầy đủ và hỗ trợ kịp thời cho người sử dụng.
Khả năng bảo hành và duy trì hoạt động của hệ thống là yếu tố quan trọng, yêu cầu hệ thống phải có khả năng cập nhật, thay đổi và mở rộng để đáp ứng nhu cầu biến đổi của khách hàng.
Tính tin cậy của phần mềm bao gồm khả năng thực hiện chính xác các nhiệm vụ được thiết kế và đảm bảo an toàn, an ninh dữ liệu Hệ thống cần duy trì hoạt động bình thường ngay cả khi xảy ra các sự kiện bất thường.
Tính hiệu quả của phần mềm được thể hiện qua khả năng tối ưu hóa việc sử dụng tài nguyên như bộ nhớ, bộ xử lý, thiết bị ngoại vi và thời gian Phần mềm hiệu quả không chỉ giảm thiểu lãng phí tài nguyên mà còn nâng cao hiệu suất làm việc, giúp người dùng tiết kiệm thời gian và chi phí.
Phân loại hệ thống phần mềm
Khi phân loại hệ thống phần mềm, cần xem xét nội dung thông tin được xử lý cùng với đặc điểm của môi trường hệ thống.
1 Hệ thống thông tin quản lý (Management Information System - MIS): hệ thống cung cấp các thông tin cần thiết cho công tác quản lý và điều hành của một doanh nghiệp, cơ quan, hay nói rộng ra là cho một tổ chức Hạt nhân của hệ thống thông tin quản lý là một cơ sở dữ liệu (CSDL) chứa các thông tin phản ánh tình trạng hiện thời và các kết quả hoạt động sản xuất, kinh doanh của tổ chức đó Hệ thống thu thập các thông tin từ môi trường hoạt động của doanh nghiệp, kết hợp với các thông tin có trong CSDL để kết xuất các thông tin mà các nhà quản lý cần, đồng thời thường xuyên cập nhật dữ liệu để giữ cho các thông tin ở trong CSDL luôn phản ánh đúng thực trạng hiện thời của tổ chức đó Hệ thống thông tin quản lý thường được phân loại theo hai mức:
Mức thấp, hay còn gọi là mức tác nghiệp, là hệ thống chủ yếu thực hiện việc in ấn các bảng biểu và chứng từ giao dịch theo các biểu mẫu truyền thống Hệ thống này thường được áp dụng trong các lĩnh vực như xử lý đơn hàng, quản lý nhân sự, quản lý thiết bị, vật tư, và kế toán tài chính.
Mức cao, hay còn gọi là mức điều hành, là hệ thống cung cấp thông tin chiến lược và kế hoạch, giúp lãnh đạo đưa ra quyết định đúng đắn trong quản lý hoạt động của đơn vị Ví dụ, các hệ thống dịch vụ công và thông tin tổng hợp đang được xây dựng trong Đề án 112 của Chính phủ có thể phát triển thành hệ hỗ trợ quyết định (DSS) Hệ thống này không chỉ bao gồm cơ sở dữ liệu mà còn tích hợp các mô hình và phương pháp, cho phép người dùng tìm ra các giải pháp và kết quả đa dạng dựa trên dữ liệu khi đưa ra quyết định.
2 Các hệ thống kỹ thuật (Technical Systems), những hệ thống tự động hoá sản xuất hay còn gọi là các hệ thống điều khiển các quá trình Đó là những hệ thống nhằm xử lý và điều khiển tự động các quá trình vận hành các thiết bị kỹ thuật trong sản xuất, viễn thông, quân sự, các quá trình công nghiệp, v.v Những hệ thống này thường phải làm việc theo phương thức xử lý thời gian thực Về mặt kiến trúc vật lý, bên cạnh phần mềm, hệ thống này bao gồm nhiều loại thiết bị tin học đa dạng: từ các CPU phổ dụng, đến các máy tính chuyên dụng, các ôtômát lập trình được, như các bộ điều khiển logic lập trình được (Programmable Logic Controller – PLC), các đường truyền, các bộ cảm biến, các bộ chuyển đổi tín hiệu A/N hay N/A
3 Các hệ thống nhúng thời gian thực (Embedded Real_time System) Hệ thống thực hiện trên những thiết bị cứng đơn giản và được nhúng vào các thiết bị khác như: mobile phone, hệ thống hướng dẫn lái xe ô tô, hệ thống điều khiển các dụng cụ dân dụng, v.v Các hệ thống này thường được thực hiện lập trình ở mức thấp, và cũng thường thực hiện xử lý theo thời gian thực Trong các hệ này, thường thiếu vắng các thiết bị ngoại vi thông dụng như màn hình, ổ đĩa cứng, v.v
4 Phần mềm hệ thống (System Software) Những hệ thống này thiết lập nên hạ tầng kỹ thuật của các hệ thống máy tính, phục vụ cho các phần mềm ứng dụng chạy trên đó Đó có thể là hệ điều hành, hệ quản trị CSDL, chương trình dịch, giao diện phần mềm ứng dụng API (Application
Giao diện lập trình (Programming Interface) tận dụng các dịch vụ tầng thấp của phần cứng, cung cấp các giao diện và dịch vụ ở tầng cao một cách khái quát và dễ sử dụng cho các ứng dụng.
5 Các hệ thống tự động hoá văn phòng (Automated Office Ssystems) Tự động hoá văn phòng là cách tiếp cận nhằm đưa máy tính vào hoạt động văn phòng, cho phép thâu tóm mọi công việc tính toán, giao lưu, quản lý thông tin, tất cả vào trong các cửa sổ trên màn hình máy tính, có ngay trên bàn làm việc của mỗi nhân viên văn phòng Một hệ thống tự động hoá văn phòng phải cung cấp được ít nhất một số trong các chức năng chính như sau:
Thư tín điện tử (E-mail): nhận/gửi các thông điệp văn bản (Text messages) tới các cá nhân hay nhóm người
Lịch biểu, kế hoạch công tác, thông báo, v.v
Xử lý văn bản: soạn thảo, sửa chữa, mi trang, v.v các tài liệu, biểu đồ, văn tự và đồ hoạ
Hội thảo điện tử là hình thức hội thảo nghe nhìn từ xa, cho phép trao đổi dữ liệu và tổ chức các cuộc tọa đàm kết hợp giữa dữ liệu, tiếng nói và hình ảnh Nó giúp nối ghép các màn hình lại với nhau, tạo ra trải nghiệm tương tác hiệu quả.
Các hệ thống tích hợp điện thoại với khả năng xử lý và tính toán của máy tính cho phép người dùng truy cập vào các hệ cơ sở dữ liệu (CSDL) thông qua điện thoại, bao gồm cả điện thoại không dây, nhằm đáp ứng nhu cầu dịch vụ cần thiết.
Mỗi loại phần mềm đều có những phương pháp, mô hình, công cụ và quy trình riêng biệt Do đó, khi phát triển hệ thống phần mềm, việc xác định loại phần mềm là cần thiết để lựa chọn giải pháp phù hợp và hiệu quả nhất.
Sự phát triển hệ thống
Chu trình phát triển hệ thống
Có nhiều loại chu trình phát triển phần mềm khác nhau Ivan Sommerville
[19 ] nói tới năm loại chu trình phát triển chính
Mô hình thác nước (Waterfall) là chu trình phát triển phần mềm đầu tiên được Royce đề xuất vào năm 1970, nhằm mô tả quy trình phát triển hệ thống thông tin Quá trình này được chia thành các giai đoạn liên tiếp, bao gồm phân tích yêu cầu, phân tích các thành phần, thiết kế, lập trình, thử nghiệm và triển khai hệ thống Mỗi giai đoạn chỉ bắt đầu khi giai đoạn trước đã hoàn thành, do đó mô hình này còn được gọi là chu trình tuyến tính.
Mô hình phát triển phần mềm theo chu trình thác nước được thiết lập dựa trên cách tiếp cận chức năng, phù hợp cho các dự án lớn và phức tạp Tuy nhiên, nhược điểm lớn nhất của mô hình này là thiếu khả năng quay lui, điều này gây khó khăn khi phát hiện thiếu sót ở các giai đoạn sau Sự quay lui là cần thiết trong phát triển phần mềm, vì nhiều khi các vấn đề chỉ được nhận ra khi đã hoàn thành giai đoạn tiếp theo Hơn nữa, trong chu trình thác nước, người dùng không tham gia trực tiếp vào từng giai đoạn, mà chỉ tiếp xúc với sản phẩm sau khi hoàn tất.
Hình 1.1: Chu trình thác nước
Nhiều phương pháp cải tiến chu trình thác nước đã được đề xuất, cho phép quay lui trong quá trình phát triển Một ví dụ là chu trình hình chữ V do AFCIQ (Association Française pour le Contrôle Industriel de la Qualité) đề xuất, bao gồm các bước quay lui và tích hợp các pha kiểm thử trong giai đoạn phân tích và thiết kế Khi phát hiện sai sót, giai đoạn tương ứng sẽ được xem lại và chu trình sẽ bắt đầu lại từ đó.
Chu trình tăng trưởng, được D R Graham giới thiệu vào năm 1989, bao gồm các bước tăng trưởng dần dần, cho phép hoàn thiện hệ thống theo từng phần Mỗi bước trong chu trình này thực hiện một tiến trình tuyến tính, bao gồm các giai đoạn phân tích, thiết kế, lập trình, kiểm định và chuyển giao từng phần.
(Hình 1.2) Quá trình này lặp lại nhiều lần cho đến khi có được phương án hoàn chỉnh cho cả hệ thống
Hình 1.2: Chu trình phát triển phần mềm tăng trưởng
Rõ ràng cách làm này chỉ thích hợp với các hệ thống có thể chia cắt và chuyển giao theo từng phần
(iii) Chu trỡnh xoắn ốc Chu trỡnh xoắn ốc hay chu trỡnh lặp được Boởhm đề xuất năm 1988, với các đặc điểm sau:
Xác định bài toán và đặc tảcác yêu cầu
Kiểm định Khai thác và bảo trì
Chuyển giao phần 1 Phân tích Thiết kế Lập trình Kiểm định
Chuyển giao phần 2 Phân tích Thiết kế Lập trình Kiểm định
Tiến trình lặp lại một dãy các giai đoạn nhất định,
Qua mỗi vòng lặp, tạo ra một nguyên mẫu và được hoàn thiện dần,
Trong quá trình phát triển phần mềm, việc khắc phục các nguy cơ và rủi ro là rất quan trọng, đặc biệt là những nguy cơ phát sinh từ sai sót trong đặc tả yêu cầu.
Trong tin học, phần mềm nguyên mẫu (Prototype) là một hệ thống:
Có khả năng xử lý dữ liệu thực tế, sản phẩm đã vượt qua giai đoạn thử nghiệm lý thuyết và có thể được đánh giá bởi nhà thiết kế hoặc khách hàng.
Có khả năng mở rộng để tiến tới một hệ thống hoàn chỉnh hoặc làm nền tảng cho việc phát triển hệ thống theo yêu cầu Quá trình tạo lập diễn ra nhanh chóng và tiết kiệm chi phí.
Dùng để kiểm chứng các giả định về nhu cầu cần đáp ứng, các lược đồ thiết kế về logic của các chương trình
Như vậy, việc tạo ra các nguyên mẫu nhanh chóng là có ích trên nhiều phương diện:
Chính xác hóa yêu cầu hệ thống là rất quan trọng, vì nhu cầu của người dùng thường không được diễn đạt rõ ràng Sử dụng nguyên mẫu giúp người dùng trực quan hóa và đánh giá xem sản phẩm có đáp ứng đúng nhu cầu của họ hay không.
Việc phát hiện hành vi lệch lạc và sai sót trong thiết kế là rất quan trọng, bởi vì người thiết kế không thể lường hết mọi tình huống nhạy cảm Xây dựng nguyên mẫu giúp phát hiện các khiếm khuyết của hệ thống và đánh giá hiệu năng của nó Hiệu năng hệ thống liên quan chặt chẽ đến ngôn ngữ lập trình, nền tảng và phần cứng như máy tính Nguyên mẫu không chỉ phản ánh hiệu năng tương đối của chương trình mà còn giúp xác định nguyên nhân gây ra sự chậm chạp từ bên trong chương trình và các khâu giao tiếp người/máy.
Kỹ thuật làm nguyên mẫu hiện nay được thực hiện hiệu quả nhờ vào các ngôn ngữ lập trình phi thủ tục, hay còn gọi là ngôn ngữ thế hệ thứ tư, bao gồm cả ngôn ngữ hướng đối tượng Hầu hết sản phẩm phần mềm tại Việt Nam, đặc biệt là những phần mềm phục vụ chương trình cải cách hành chính của Chính phủ, được phát triển dựa trên kỹ thuật làm nguyên mẫu trong chu trình xoắn ốc Ban điều hành Đề án 112 tổ chức và quản lý quá trình thực hiện một cách chặt chẽ qua từng giai đoạn, đồng thời thường xuyên trao đổi, thảo luận và đánh giá kết quả đạt được Trên cơ sở đó, họ đưa ra các tài liệu mẫu để hướng dẫn các nhóm thực hiện, đảm bảo phần mềm phát triển đúng theo yêu cầu.
Quá trình phát triển phần mềm theo phương pháp nguyên mẫu có sự khác biệt rõ rệt so với quy trình tuyến tính truyền thống Theo nghiên cứu của Jekins, Milton và Naumann từ Đại học Indiana City, chu trình xoắn ốc được chia thành bốn giai đoạn cho mỗi vòng lặp chính.
Hình 1.3: Chu trình xoắn ốc
Giai đoạn 1 bao gồm vòng lặp đầu tiên, nơi tập trung vào việc phát hiện các yêu cầu cơ bản thông qua các phương pháp như khảo sát, phỏng vấn và xem xét tài liệu Mục tiêu là nhanh chóng xác định các yêu cầu rõ nét mà không cần đi sâu vào chi tiết, từ đó chuyển sang giai đoạn tiếp theo Ở vòng lặp thứ hai, giai đoạn này sẽ xác định các mục tiêu cụ thể của vòng lặp hiện tại, các phương án khả thi và các ràng buộc dựa trên kết quả của vòng lặp trước.
Giai đoạn 2 bao gồm việc đánh giá các phương án khả thi, phát hiện các nguy cơ tiềm ẩn và tìm kiếm giải pháp cho chúng Các nguy cơ và rủi ro có thể đến từ công nghệ mới, đối thủ cạnh tranh, thị trường, khách hàng, ngân sách và tài chính Dựa trên những yếu tố này, việc đánh giá tính khả thi của dự án trở nên cần thiết.
Giai đoạn 3: Thiết kế và tạo lập nguyên mẫu, tập trung vào những điều cốt yếu
Giai đoạn 4: Thử nghiệm nguyên mẫu là bước quan trọng trong quy trình phát triển sản phẩm Trong giai đoạn này, nguyên mẫu được giới thiệu cho một nhóm người dùng chọn lọc nhằm thu thập phản hồi và ý kiến đóng góp Dựa trên mức độ quan trọng của các phản hồi nhận được, những điều chỉnh cần thiết sẽ được thực hiện trong các vòng thử nghiệm tiếp theo.
Các vòng lặp được tiếp tục cho đến khi xét thấy nguyên mẫu là tốt thì có thể chuyển sang sản xuất thực sự
Một số người cho rằng phương pháp vòng vo sẽ kéo dài thời gian Tuy nhiên, nghiên cứu của Boờhm và Gray chỉ ra rằng thời gian có thể rút ngắn đến 45% so với phương pháp truyền thống.
Thử nghiệm và đánh giá nguyên mẫu
Xác định mục tiêu, phương án và các ràng buộc Đánh giá các phương án
Thiết kế và tạo lập nguyên mẫu
Mô hình hoá hệ thống
Các bước phát triển hệ thống, bao gồm tìm hiểu nhu cầu, phân tích, thiết kế và lập trình, mặc dù khác nhau về nhiệm vụ và mục tiêu, nhưng đều đối mặt với sự phức tạp của các bài toán ứng dụng Tất cả các bước này đều là quá trình nhận thức và diễn tả sự phức tạp thông qua các mô hình.
Nói cách khác đều là quá trình thực hiện mô hình hoá để hiểu và xây dựng hệ thống
Nguyên lý chế ngự sự phức tạp là một phương pháp quan trọng trong nghiên cứu thế giới phức tạp, trong đó mọi khoa học thực nghiệm đều áp dụng nguyên lý "Chia để trị" để phân tích và hiểu rõ hơn về các hiện tượng.
Nguyên lý "Trừu tượng hoá" trong phương pháp "Chia để trị" yêu cầu người học bỏ qua những chi tiết nhỏ để nắm bắt bản chất vấn đề Trừu tượng hoá giúp đơn giản hóa các khái niệm phức tạp, từ đó tạo điều kiện cho việc phân tích và giải quyết vấn đề hiệu quả hơn.
Chủ đề không liên quan đến ý định hiện tại giúp chúng ta tập trung hoàn toàn vào những sắc thái liên quan đến ý định đó, theo định nghĩa từ Từ điển Oxford.
Trước khi giải quyết một bài toán, chúng ta cần bỏ qua những chi tiết không quan trọng, từ đó tạo ra một mô hình đơn giản và dễ hiểu Điều này giúp chúng ta tập trung vào bản chất của vấn đề và tìm ra giải pháp thực tiễn hiệu quả hơn.
(ii) Mô hình (Model) là một dạng trừu tượng hoá của hệ thống thực
Mô hình là hình ảnh trừu tượng của bài toán đang được nghiên cứu, thể hiện qua một quan điểm nhất định và có thể được diễn đạt bằng nhiều hình thức như văn bản, bảng biểu, biểu đồ, đồ thị, công thức hay phương trình toán học.
Ngày nay, các phương pháp phân tích và thiết kế hệ thống ngày càng ưa chuộng việc sử dụng mô hình biểu đồ Đặc biệt, phương pháp hướng đối tượng với UML cho phép diễn tả rõ ràng và trực quan các khái niệm cũng như kết quả của từng bước trong quá trình phát triển phần mềm thông qua các biểu đồ theo ký pháp thống nhất.
(iii) Mục đích của mô hình hoá Có năm mục đích chính
1 Mô hình giúp ta hiểu và thực hiện được sự trừu tượng, tổng quát hoá các khái niệm cơ sở để giảm thiểu độ phức tạp của hệ thống Qua mô hình chúng ta biết được hệ thống gồm những gì? và chúng hoạt động như thế nào? Jean Piaget từng nói: “Hiểu tức là mô hình hoá” Do vậy, quá trình phát triển phần mềm nêu trên chẳng qua là quá trình nhận thức và diễn tả hệ thống đó Đó cũng là quá trình thiết lập, sử dụng và biến đổi các mô hình Có một mô hình đúng sẽ giúp ta làm sáng tỏ những vấn đề phức tạp và cho ta cái nhìn thấu đáo về vấn đề cần giải quyết
2 Mô hình giúp chúng ta quan sát được hệ thống như nó vốn có trong thực tế hoặc nó phải có như ta mong muốn Muốn hiểu và phát triển được hệ thống phần mềm theo yêu cầu thực tế thì ta phải quan sát nó theo nhiều góc nhìn khác nhau: theo chức năng sử dụng, theo các thành phần logic, theo phương diện triển khai, v.v
3 Mô hình cho phép ta đặc tả được cấu trúc và hành vi của hệ thống để hoàn chỉnh:
Đảm bảo rằng hệ thống đạt được mục tiêu đã được xác định trước là rất quan trọng Mặc dù mọi mô hình đều đơn giản hóa thế giới thực, nhưng cần phải giữ lại những yếu tố quan trọng để tránh làm mất đi tính chính xác và hiệu quả của hệ thống.
Quá trình mô hình hoá cho phép kiểm tra các quy định về cú pháp và ngữ nghĩa, đảm bảo tính chặt chẽ và đầy đủ của mô hình Điều này khẳng định tính đúng đắn của thiết kế, đồng thời phù hợp với yêu cầu của khách hàng Mô hình hoá không chỉ là một bước đơn lẻ mà là một quá trình hoàn thiện và tiến hoá liên tục.
4 Mô hình hoá là nhằm tạo ra khuôn mẫu (template) và hướng dẫn cách xây dựng hệ thống; cho phép thử nghiệm, mô phỏng và thực hiện theo mô hình
5 Mô hình là cơ sở để trao đổi, ghi lại những quyết định đã thực hiện trong nhóm tham gia dự án phát triển phần mềm Mọi quan sát, mọi sự hiểu biết (kết quả phân tích, thiết kế, lập trình) đều phải được ghi lại chi tiết để phục vụ cho cả quá trình phát triển và bảo trì hệ thống Vì tính hiểu được của mô hình mà nó trở thành một thứ ngôn ngữ chung để trao đổi giữa những người cùng tham gia trong một dự án cũng như giữa những người phát triển phần mềm với khách hàng
Mỗi hệ thống thực tế có thể được tiếp cận qua nhiều mô hình khác nhau, và không có mô hình nào là hoàn chỉnh Quá trình mô hình hóa hệ thống phần mềm thường diễn ra theo hai cấp độ.
+ Mô hình logic: mô tả các thành phần và mối quan hệ của chúng để thực hiện các nhu cầu hệ thống,
+ Mô hình vật lý: xác định kiến trúc các thành phần và tổng thể của hệ thống
Tóm lại, mô hình hoá một hệ thống phải thực hiện theo cả bốn hướng:
Hình 1.5: Các hướng mô hình hoá
Có bố n yếu tố quan trọ ng ảnh hưở ng tới hiệu quả c ủa dự án phát triển phần mềm:
1 Con người Yếu tố quan trọng nhất hiển nhiên là số lượng và trình độ chuyên nghiệp của những người tham gia phát triển phần mềm, những người có khả năng nắm bắt, làm chủ được những công nghệ mới, có khả năng hiểu được bài toán của lĩnh vực ứng dụng
Các cách tiếp cận trong phát triển phần mềm
Cách tiếp cận hướng chức năng
Hầu hết các chương trình được phát triển bằng ngôn ngữ lập trình như C hay Pascal thường sử dụng phương pháp lập trình hướng chức năng, hay còn gọi là lập trình hướng thủ tục Phương pháp này có những đặc điểm nổi bật như việc tập trung vào các hàm và quy trình, giúp tổ chức mã nguồn một cách có hệ thống và dễ quản lý.
Khi khảo sát và phân tích một hệ thống, chúng ta thường chú trọng vào các nhiệm vụ chính mà hệ thống cần thực hiện Để xây dựng “hệ thống quản lý thư viện”, trước tiên, cần nghiên cứu yêu cầu từ người dùng như thủ thư và bạn đọc để xác định các chức năng thiết yếu như quản lý bạn đọc, cho mượn sách, nhận trả sách, và thông báo nhắc trả sách Sau khi đã hiểu rõ bài toán và yêu cầu hệ thống, các chức năng và nhiệm vụ này hầu như không thay đổi trong quá trình phát triển tiếp theo, trừ khi có sự khảo sát lại Dựa vào các chức năng chính, dữ liệu sẽ linh hoạt và biến đổi để phục vụ cho các nhiệm vụ đó, do đó, hệ thống phần mềm được coi là tập hợp các chức năng và nhiệm vụ cần được thực thi.
Phân rã chức năng theo cách từ trên xuống (Top/Down) giúp quản lý độ phức tạp của các vấn đề thực tế bằng cách chia nhỏ các chức năng chính thành các chức năng đơn giản hơn Quá trình này được lặp lại cho đến khi đạt được các đơn thể chức năng đơn giản, dễ hiểu và có thể thực hiện mà không làm tăng thêm độ phức tạp Độ phức tạp của hệ thống thường tỉ lệ nghịch với độ phức tạp của các đơn thể chức năng Một thách thức quan trọng là xác định khi nào quá trình phân tách này nên dừng lại, điều này phụ thuộc vào độ phức tạp của bài toán và trình độ của nhóm phát triển phần mềm Hệ thống sẽ được phân tích dựa trên các chức năng hoặc quy trình, từ đó tạo ra cấu trúc phân cấp các chức năng và các hệ thống con.
Hầu hết các hệ thống thông tin quản lý có thể được tổ chức thành sơ đồ chức năng theo cấu trúc phân cấp có thứ bậc, cho phép khẳng định rõ ràng về các chức năng của chúng.
Các đơn thể chức năng trong hệ thống phần mềm cần trao đổi thông tin và dữ liệu để hoạt động hiệu quả Để đảm bảo sự liên kết giữa các chương trình con thực hiện các chức năng khác nhau, việc sử dụng dữ liệu chung hoặc truyền tham số là rất quan trọng Mỗi đơn thể chức năng không chỉ thao tác trên dữ liệu cục bộ mà còn cần sử dụng các biến toàn cục để tăng cường khả năng tương tác và đồng bộ hóa trong hệ thống.
Việc sử dụng biến toàn cục trong thiết kế và lập trình có thể gây ra nhiều bất lợi, đặc biệt trong các dự án lớn và phức tạp với nhiều nhóm tham gia Khi một nhóm cần thay đổi dữ liệu chung, các nhóm khác cũng buộc phải điều chỉnh theo, dẫn đến việc thay đổi một chức năng có thể ảnh hưởng đến các chức năng khác Điều này không chỉ làm giảm hiệu suất lao động mà còn gây khó khăn trong việc quản lý yêu cầu thay đổi, vì nhu cầu điều chỉnh các chức năng là điều tất yếu và thường xuyên xảy ra.
(iv) Tính mở (Open) và thích nghi của hệ thống được xây dựng theo cách tiếp cận này là thấp vì:
Hệ thống thường được xây dựng dựa trên chức năng chính, nhưng thực tế cho thấy các chức năng và nhiệm vụ của hệ thống thường xuyên thay đổi Việc đảm bảo hệ thống thực hiện đúng các yêu cầu, đặc biệt là các yêu cầu chức năng thay đổi, là một công việc phức tạp và tốn kém Chẳng hạn, khi giám đốc thư viện yêu cầu thay đổi cách quản lý bạn đọc hoặc bổ sung chức năng theo dõi tài liệu mới, việc bảo trì hệ thống phần mềm trở nên khó khăn Nhiều khi, những yêu cầu thay đổi cơ bản không thể sửa đổi hiệu quả, dẫn đến nhu cầu phải phân tích và thiết kế lại hệ thống từ đầu.
Hệ thống cần sử dụng biến toàn cục để các bộ phận giao tiếp, nhưng điều này hạn chế khả năng thay đổi và mở rộng của cả hệ thống Những thay đổi liên quan đến dữ liệu chung có thể ảnh hưởng đến tất cả các bộ phận, vì vậy thiết kế tốt nên dễ hiểu và cho phép sửa đổi chỉ có hiệu ứng cục bộ.
Khả năng tái sử dụng (Reuse) trong hệ thống phần mềm thường bị hạn chế và thiếu cơ chế kế thừa (Inheritance), khiến cho các thành phần cần phải tự chứa để đạt độ thích nghi tốt Để hoàn toàn tự chứa, các thành phần không nên phụ thuộc vào nhiều yếu tố ngoại lai, điều này mâu thuẫn với kinh nghiệm cho thấy cần phải tái sử dụng các thành phần hiện có Do đó, cần tìm sự cân bằng giữa lợi ích của việc tái sử dụng (chủ yếu là cấu trúc và hàm) và tính thích nghi của chúng Các thành phần trong hệ thống cần có độ kết dính (Cohesion) nhưng cũng phải linh hoạt để dễ dàng thích ứng Kế thừa là một cơ chế chính hỗ trợ tính thích nghi, trong khi tiếp cận hướng chức năng lại không cung cấp sự hỗ trợ này Cơ chế kế thừa giúp đơn giản hóa việc định nghĩa các khái niệm tương tự dựa trên những thực thể đã được định nghĩa trước, từ đó cho phép thực hiện nguyên lý tổng quát hóa và chi tiết hóa các thành phần trong hệ thống phần mềm.
Cách tiếp cận hướng đối tượng
Để khắc phục các vấn đề trong phát triển phần mềm, cần nghiên cứu các phương pháp, mô hình và công cụ mới Mô hình hướng đối tượng có thể giúp vượt qua khủng hoảng công nghệ phần mềm, mang lại sản phẩm thương mại chất lượng cao, đáng tin cậy, dễ mở rộng và thích nghi với yêu cầu của khách hàng Cách tiếp cận này có những đặc trưng nổi bật.
Khi khảo sát và phân tích một hệ thống, chúng ta cần đặt trọng tâm vào dữ liệu thực thể thay vì chỉ tập trung vào các nhiệm vụ Thực thể, hay còn gọi là đối tượng, bao gồm những yếu tố như người, vật, sự kiện và khái niệm mà chúng ta quan tâm Ví dụ, trong việc xây dựng "Hệ thống quản lý thư viện", điều quan trọng là xác định các lớp đối tượng như Sách, Tạp_Chí và Bạn_Đọc để hiểu rõ hơn về cấu trúc của hệ thống.
Hệ thống có thể được xem như một tập hợp các thực thể và đối tượng, và để hiểu rõ hơn về nó, chúng ta cần phân tách hệ thống thành các đơn thể đơn giản hơn Quá trình này lặp lại cho đến khi đạt được những đơn thể dễ hiểu và có thể cài đặt mà không làm tăng độ phức tạp của hệ thống Các đối tượng trong hệ thống có mối quan hệ với nhau thông qua các loại quan hệ như kết hợp, kết nhập, kế thừa và sự phụ thuộc Phương pháp hướng đối tượng cho phép chúng ta đặc tả đầy đủ các mối quan hệ này, phản ánh đúng bản chất tự nhiên của thế giới thực.
Các lớp trong lập trình hướng đối tượng giao tiếp thông qua các thông điệp (Message), với lớp được định nghĩa là nhóm các đối tượng có đặc tính hoặc hành vi tương tự Lớp bao gồm các thuộc tính (Attributes) và phương thức (Methods) thể hiện đặc điểm của từng đối tượng, đồng thời tạo ra giao diện để tương tác với các đối tượng khác Khi cần dữ liệu để thực hiện nhiệm vụ, một đối tượng sẽ gửi thông điệp đến đối tượng khác, và đối tượng nhận sẽ xử lý yêu cầu bằng cách sử dụng dữ liệu của mình hoặc yêu cầu hỗ trợ từ các đối tượng khác Nhờ vào cách xử lý này, lập trình hướng đối tượng có thể giảm thiểu việc sử dụng biến toàn cục.
(iv) Tính mở và thích nghi của hệ thống cao hơn vì:
Hệ thống được xây dựng dựa trên các lớp đối tượng, cho phép thay đổi linh hoạt khi có yêu cầu mới Chỉ cần điều chỉnh các lớp liên quan hoặc thêm lớp mới, kế thừa từ các lớp hiện có, để thực hiện nhiệm vụ mới Ví dụ, khi giám đốc thư viện yêu cầu theo dõi tài liệu mới mà bạn đọc thường xuyên yêu cầu đặt mua, ta có thể bổ sung lớp Yêu_Cầu để đáp ứng nhu cầu này.
• Trong các chương trình hướng đối tượng có thể không cần sử dụng biến toàn cục nên mọi sửa đổi chỉ có hiệu ứng cục bộ
(v) Hỗ trợ sử dụng lại và cơ chế kế thừa Các lớp đối tượng được tổ chức theo nguyên lý bao gói (Encapsulation) và che giấu thông tin (Information
Phương pháp lập trình hướng đối tượng, bao gồm các ngôn ngữ như C++, Java, C# và Delphi, tăng cường hiệu quả của kế thừa và độ tin cậy của hệ thống Một trong những ưu điểm chính của phương pháp này là khả năng sử dụng quan hệ kế thừa, giúp tối ưu hóa mã nguồn và cải thiện khả năng bảo trì.
Đối tượng đóng vai trò quan trọng trong việc kết hợp các đơn thể có thể tái sử dụng thành một hệ thống lớn hơn, từ đó tạo ra những sản phẩm chất lượng cao Điều này cũng là nền tảng để áp dụng công nghệ thành phần hiệu quả.
Qui ước truyền thông điệp giữa các đối tượng giúp mô tả giao diện giữa các thành phần trong hệ thống và các hệ thống bên ngoài một cách dễ dàng Điều này hỗ trợ trong việc phân chia các dự án lớn, phức tạp, cho phép phân tích và thiết kế bằng cách chia nhỏ bài toán thành các lớp đối tượng tương ứng, phù hợp với quan điểm giải quyết vấn đề trong thế giới thực một cách tự nhiên.
• Nguyên lý bao gói, che giấu thông tin hỗ trợ cho việc xây dựng những hệ thống thông tin an toàn và tin cậy
Nguyên lý kế thừa dựa vào dữ liệu giúp tối ưu hóa mô hình trong cài đặt, không chỉ giảm thời gian thực hiện mà còn nâng cao tính mở và độ tin cậy của hệ thống.
Phương pháp hướng đối tượng, đặc biệt là nguyên lý kế thừa, giúp xác định dễ dàng các bộ phận cơ bản và xây dựng các lớp như đơn vị cơ sở của hệ thống Điều này cho phép sử dụng các lớp ngay lập tức mà không cần hoàn thiện đầy đủ tất cả các chức năng, đồng thời hỗ trợ mở rộng mà không ảnh hưởng đến các đơn thể khác và không yêu cầu thiết kế lại.
Định hướng đối tượng cung cấp công cụ và môi trường hiệu quả cho phát triển phần mềm theo hướng công nghiệp, hỗ trợ khả năng kế thừa và tái sử dụng rộng rãi Điều này giúp xây dựng các hệ thống phức tạp và nhạy cảm như hệ thống động, hệ thống thời gian thực và hệ thống đa phương tiện.
Xoá bỏ hố ngăn cách giữa các pha phân tích, thiết kế, cài đặt và kiểm định trong quá trình xây dựng phần mềm giúp tối ưu hóa quy trình phát triển Nhiều kết quả từ các giai đoạn trước có thể được tận dụng ngay trong các giai đoạn tiếp theo, nâng cao hiệu quả và giảm thiểu thời gian triển khai.
Để hiểu rõ về các vấn đề cần mô hình hóa, ngoài việc nắm vững các khái niệm cơ bản của phương pháp luận, chúng ta cũng cần tìm hiểu các tính chất và đặc trưng của hệ thống và phương pháp đó Điều này có thể được thực hiện thông qua việc nghiên cứu các kết quả liên quan đến khả năng đặc tả và xử lý thông tin của các hệ thống, đặc biệt là các hệ thống hướng đối tượng, nhằm phân tích hành vi và các tính chất đảm bảo tính nhất quán thông tin trong mô hình hệ thống.
28] và những vấn đề chuyển đổi tương đương giữa các mô hình dữ liệu [30, 32, 34].
Quá trình phát triển phần mềm hợp nhất
Phần mềm là sản phẩm được phát triển và chế tạo tương tự như các sản phẩm công nghiệp khác, như phần cứng Quá trình phát triển phần mềm và chế tạo phần cứng có nhiều điểm tương đồng, cả hai đều là sản phẩm chất lượng phụ thuộc vào thiết kế và con người.
Tuy nhiên, phần mềm và phần cứng lại có nhiều điểm đặc trưng rất khác nhau
Quá trình và phương pháp sản xuất phần cứng và phần mềm có sự khác biệt rõ rệt; phần cứng thường được sản xuất hàng loạt trên dây chuyền, trong khi phần mềm thường được phát triển theo yêu cầu, theo từng đơn đặt hàng riêng biệt.
Các giai đoạn chế tạo phần cứng có thể được xác định và điều chỉnh để nâng cao chất lượng sản phẩm, trong khi việc thay đổi chất lượng phần mềm lại gặp nhiều khó khăn hơn.
• Mối quan hệ giữa người sử dụng và công việc cần thực hiện với từng loại sản phẩm là hoàn toàn khác nhau,
Cách tiếp cận trong việc xây dựng và chế tạo sản phẩm có sự khác biệt rõ rệt, dẫn đến khả năng nhân bản của chúng cũng không giống nhau Đặc biệt, việc bảo vệ bản quyền sản phẩm phần mềm gặp nhiều thách thức do khả năng sao chép dễ dàng và nhanh chóng, khiến cho việc duy trì tính độc quyền trở nên khó khăn hơn.
• Phần mềm khác hẳn với phần cứng là không bị hư hỏng theo thời gian, không bị tác động của môi trường (thời tiết, nhiệt độ, điều kiện, v.v…)
Bảo hành phần cứng đảm bảo thiết bị hoạt động như mới, trong khi bảo hành phần mềm tập trung vào việc duy trì hệ thống theo đúng thiết kế và đáp ứng nhu cầu của khách hàng Do đó, chi phí cho bảo trì phần mềm thường cao và yêu cầu sự chú trọng đặc biệt vào phân tích và thiết kế hệ thống.
Tất cả các hệ thống phần mềm đều hoạt động trong một môi trường cụ thể, không thể tồn tại độc lập mà luôn tương tác với các yếu tố xung quanh Một hệ thống có thể được coi là một phần của một hệ thống lớn hơn, đồng thời cũng có khả năng chứa các hệ thống con nhỏ hơn bên trong nó.
Công nghệ phần cứng đang phát triển nhanh chóng với chất lượng và tốc độ xử lý ngày càng cao, trong khi giá phần mềm vẫn cao Để phát triển hệ thống phần mềm đáp ứng yêu cầu, cần áp dụng lý thuyết, kỹ nghệ, phương pháp và công cụ mới, tạo ra quy trình phát triển phần mềm hợp nhất Công nghệ phần mềm (CNPM) bao gồm lý thuyết, phương pháp luận và công cụ cần thiết nhằm sản xuất phần mềm chất lượng cao, tin cậy, trong giới hạn nguồn lực và ngân sách, theo đúng lịch trình Ngoài việc phát triển hệ thống phần mềm, CNPM còn yêu cầu tạo ra tài liệu như thiết kế và hướng dẫn sử dụng, làm cơ sở cho bảo trì và phát triển hệ thống sau này.
Tóm lại, để xây dựng được những hệ thống phần mềm đáp ứng những yêu cầu trên, chúng ta cần phải:
• Có một qui trình phát triển phần mềm thống nhất gồm các bước thực hiện rõ ràng, mà sau mỗi bước đều phải có các sản phẩm cụ thể;
• Có các phương pháp và kỹ nghệ phù hợp với từng giai đoạn thực hiện phát triển phần mềm;
• Có công cụ để làm ra sản phẩm phần mềm theo yêu cầu
Quá trình phát triển phần mềm là việc xác định vai trò, thời gian và phương thức thực hiện các công việc cần thiết Đây là quy trình xây dựng sản phẩm phần mềm mới hoặc nâng cấp sản phẩm đã có.
Hệ thống phần mềm là sản phẩm của nhiều hoạt động sáng tạo và phát triển, đòi hỏi sự tham gia của nhiều người Khách hàng và nhà đầu tư đưa ra vấn đề cần giải quyết, trong khi các nhà phân tích, thiết kế và lập trình thực hiện việc phân tích yêu cầu, thiết kế các thành phần hệ thống và cài đặt chúng Cuối cùng, phần mềm được kiểm thử và triển khai để đáp ứng nhu cầu của người sử dụng.
Quá trình phát triển phần mềm bao gồm các hoạt động cần thiết để chuyển đổi yêu cầu của khách hàng thành hệ thống phần mềm hoàn chỉnh Có sáu bước chính trong quy trình này, mỗi bước đều đóng vai trò quan trọng trong việc đảm bảo sản phẩm cuối cùng đáp ứng đúng nhu cầu của người sử dụng.
1 Xác định và đặc tả các yêu cầu
4 Lập trình, mã hoá chương trình
6 Vận hành và bảo trì hệ thống
Có nhiều phương pháp để thực hiện các bước trong dự án, với số lượng bước đề xuất có thể khác nhau Các dự án có thể áp dụng các mô hình như "thác nước", "tạo nguyên mẫu", hay "xoắn ốc", tùy thuộc vào lĩnh vực ứng dụng và khả năng của nhóm thực hiện.
(i) Xác định các yêu cầu và phân tích hệ thống
Dựa vào yêu cầu của khách hàng, chúng ta xác định mục tiêu phát triển phần mềm, chủ yếu là các yêu cầu chức năng mà hệ thống cần thực hiện mà không cần chỉ ra cách thức thực hiện Việc xác định đầy đủ và chính xác các yêu cầu là rất quan trọng, tạo nền tảng cho các bước tiếp theo trong dự án phát triển phần mềm Để thực hiện điều này, cần có tài liệu đặc tả chi tiết các yêu cầu của hệ thống, trong đó UML cung cấp biểu đồ ca sử dụng để hỗ trợ việc này Tài liệu đặc tả yêu cầu sẽ được sử dụng để
Cơ sở để trao đổi với người sử dụng và thảo luận giữa các thành viên trong dự án phát triển phần mềm là xác định những chức năng mà hệ thống cần thực hiện, cũng như những điều không cần thiết phải thực hiện.
Làm căn cứ cơ bản để kiểm tra, thử nghiệm trong các bước tiếp theo của quá trình phát triển phần mềm
Muốn đạt được các mục tiêu trên thì quá trình phải thực hiện:
Xác định và hiểu rõ miền và phạm vi của bài toán là rất quan trọng Những người phát triển hệ thống cần nắm vững yêu cầu của khách hàng cũng như các khái niệm cơ sở liên quan đến bài toán ứng dụng để xây dựng giải pháp hiệu quả.
Để nắm bắt các yêu cầu của khách hàng, người phân tích cần trao đổi với tất cả các bên liên quan đến dự án và tham khảo tài liệu liên quan Thảo luận với khách hàng, chuyên gia trong lĩnh vực ứng dụng và người dùng hệ thống hiện tại giúp phát hiện và hiểu rõ các nhu cầu Phương pháp trừu tượng hóa hỗ trợ trong việc nhận diện các yêu cầu của hệ thống một cách dễ dàng hơn.
UML VÀ QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM
Tổng quát về UML
UML, hay ngôn ngữ mô hình hóa, là một tập hợp các ký pháp thống nhất, giúp thể hiện ngữ nghĩa của các định nghĩa trực quan cho tất cả các thành phần của mô hình Nó được sử dụng để hiển thị, đặc tả, tổ chức, xây dựng và tài liệu hóa các sản phẩm trong quá trình phát triển phần mềm hướng đối tượng, đặc biệt là trong các giai đoạn phân tích và thiết kế thông qua báo cáo, biểu đồ, bản mẫu và trang web.
UML là ngôn ngữ mô hình hoá độc lập với các công nghệ phát triển phần mềm
Mục đích chính của UML:
1 Mô hình được các hệ thống (không chỉ hệ thống phần mềm) và sử dụng được tất cả các khái niệm hướng đối tượng một cách thống nhất
2 Cho phép đặc tả, hỗ trợ để đặc tả tường minh (trực quan) mối quan hệ giữa các khái niệm cơ bản trong hệ thống, đồng thời mô tả được mọi trạng thái hoạt động của hệ thống đối tượng Nghĩa là cho phép mô tả được cả mô hình tĩnh lẫn mô hình động một cách đầy đủ và trực quan
3 Tận dụng được những khả năng sử dụng lại và kế thừa ở phạm vi diện rộng để xây dựng được những hệ thống phức tạp và nhạy cảm như: các hệ thống động, hệ thống thời gian thực, hệ thống nhúng thời gian thực, v.v
4 Tạo ra những ngôn ngữ mô hình hoá sử dụng được cho cả người lẫn máy tính
UML, hay Ngôn ngữ Mô hình Hóa, là công cụ quan trọng trong phát triển phần mềm, đặc biệt trong phân tích và thiết kế hệ thống hướng đối tượng Nó cung cấp một ngôn ngữ hình thức, thống nhất và chuẩn hóa để mô hình hóa hệ thống một cách trực quan Các thành phần trong UML được thể hiện qua các ký hiệu đồ họa và biểu đồ, giúp thể hiện rõ ràng mối quan hệ giữa chúng một cách logic và nhất quán.
Tuy nhiên cũng cần lưu ý:
UML không phải là ngôn ngữ lập trình và không thể được sử dụng để viết chương trình Nó cũng không phải là công cụ CASE, mặc dù một số công cụ CASE như Rational Rose sử dụng mô hình UML để tự động sinh mã nguồn cho các ngôn ngữ lập trình như C++, Java, và Visual C++.
UML không phải là một phương pháp hay quy trình phát triển phần mềm, mà là một tập hợp các ký hiệu được sử dụng trong các dự án phát triển phần mềm Những ký hiệu này giúp áp dụng các cách tiếp cận khác nhau cho quá trình phát triển, phân chia chu kỳ phát triển hệ thống thành các hoạt động, tác vụ, giai đoạn và bước khác nhau.
2.1.2 Quá trình phát triển phần mềm thống nhất với UML
UML được thiết kế để mô tả quá trình phát triển phần mềm và mô hình hóa hệ thống Quá trình này được biết đến với tên gọi là quá trình phát triển phần mềm hợp nhất (USPD) hay quy trình hợp nhất Rational (RUP), thường được gọi tắt là quy trình hợp nhất (UP).
RUP là bộ quy tắc hướng dẫn kỹ thuật và tổ chức trong phát triển phần mềm, tập trung chủ yếu vào các giai đoạn phân tích và thiết kế.
RUP được cấu trúc theo hai chiều:
1 Chiều thời gian: chia quá trình thành các pha thực hiện và các bước lặp
2 Chiều thành phần: các sản phẩm cùng với các hoạt động được xác định đầy đủ
1 Cấu trúc dự án theo chiều thời gian bao gồm các pha thực hiện:
(i) Khởi động (Inception): xác định dự án tổng thể
(ii) Soạn thảo dự án tỉ mỉ (Elaboration):
+ Lập kế hoặch cho những hoạt động cần thiết
+ Xác định những tài nguyên cần để thực hiện dự án
+ Xác định các tính chất, đặc trưng của dự án
+ Xây dựng kiến trúc cho hệ thống
(iii) Xác định những sản phẩm ở mỗi pha thực hiện
(iv) Chuyển giao: cung cấp sản phẩm cho cộng đồng người sử dụng
2 Cấu trúc dự án theo chiều thành phần bao gồm các hoạt động:
Mô hình hoá nghiệp vụ: thiết lập các khả năng của hệ thống cần xây dựng và nhu cầu của NSD
Phân tích các yêu cầu: chi tiết các yêu cầu chức năng và phi chức năng của hệ thống
Phân tích thiết kế hệ thống: mô tả hệ thống thực hiện các yêu cầu và hỗ trợ cài đặt
Cài đặt chương trình: lập trình những kết quả thiết kế nêu trên để hệ thống hoạt động đúng theu yêu cầu
Kiểm thử, kiểm chứng các thành phần và toàn bộ hệ thống
Triển khai hệ thống: khai thác hệ thống và huấn luyện NSD
UP bao gồm con người, dự án, sản phẩm, quy trình và công cụ Con người tham gia vào dự án để phát triển sản phẩm phần mềm, thực hiện theo một quy trình nhất định với sự hỗ trợ từ các công cụ sẵn có.
UP là phương pháp phát triển phần mềm dựa trên các ca sử dụng, trong đó yêu cầu của người sử dụng được mô tả rõ ràng Các ca sử dụng thể hiện chuỗi hành động mà hệ thống thực hiện để cung cấp dịch vụ và thông tin cho khách hàng Chúng đóng vai trò quan trọng trong việc xây dựng mô hình thiết kế và cài đặt hệ thống.
UP là quy trình tập trung vào kiến trúc, được lặp đi lặp lại và phát triển liên tục Kiến trúc hệ thống cần được thiết kế để đáp ứng yêu cầu của các ca sử dụng chính, trong giới hạn của phần cứng và cấu trúc hệ thống Tính lặp trong phát triển phần mềm thể hiện qua việc chia dự án thành các phần nhỏ, thực hiện từng bước một cách lặp lại Mỗi phần nhỏ bao gồm các giai đoạn phân tích, thiết kế, cài đặt và kiểm thử, với sự phát triển tăng trưởng cho cả từng phần và toàn bộ dự án.
UP không chỉ phát triển một hệ thống phần mềm hoàn chỉnh mà còn tạo ra các sản phẩm trung gian như mô hình nghiệp vụ, mô hình khái niệm, mô hình thiết kế, mô hình triển khai và mô hình trắc nghiệm Những mô hình này có mối quan hệ phụ thuộc theo vết phát triển, cho phép lần theo từng mô hình để truy nguyên đến mô hình trước đó.
2.1.3 Giới thiệu tổng quát về UML
UML được xây dựng dựa chính vào:
Cách tiếp cận của Booch (Booch Approach),
Kỹ thuật mô hình đối tượng (OMT – Object Modeling Technique) của Rumbaugh,
Công nghệ phần mềm hướng đối tượng (OOSE) do Jacobson phát triển đã thống nhất nhiều ký pháp và khái niệm từ các phương pháp khác nhau Quá trình hình thành ngôn ngữ mô hình hóa thống nhất (UML) bắt đầu từ ngôn ngữ Ada của Booch trước năm 1990.
Để sử dụng hiệu quả UML trong phân tích và thiết kế hệ thống, cần nắm vững ba vấn đề chính liên quan đến sự phát triển của UML.
1 Các phần tử cơ bản của UML,
2 Những qui định liên kết giữa các phần tử, các qui tắc cú pháp,
3 Những cơ chế chung áp dụng cho ngôn ngữ mô hình hoá hệ thống
2.1.4 Các phần tử của UML
Hình 2-2 Các thành phần cơ sở của UML
Để phân tích và thiết kế hệ thống, cần thực hiện các quan sát từ nhiều góc độ khác nhau Những quan sát này sẽ giúp thiết lập kiến trúc cho hệ thống đang được phát triển.
Các khái niệm cơ bản của phương pháp hướng đối tượng
Để phát triển hệ thống theo mô hình và phương pháp đã chọn, việc hiểu rõ các khái niệm cơ bản là rất quan trọng Cần thực hiện phân tích và thiết kế hệ thống theo cách tiếp cận hướng đối tượng, vì vậy trước tiên, chúng ta phải nắm bắt các khái niệm như đối tượng, lớp và mối quan hệ giữa các lớp đối tượng Những khái niệm này cũng là các phần tử cơ bản của ngôn ngữ mô hình hóa thống nhất UML.
Mô hình hướng đối tượng là phương pháp phát triển phần mềm dựa trên dữ liệu trừu tượng và khái niệm lớp, giúp thể hiện các đặc tính chung của cấu trúc dữ liệu trong việc mô hình hóa hệ thống Các khái niệm cơ bản của phương pháp này được minh họa trong hình 2-4.
2.2.1 Các đối tượng Đối tượng là khái niệm cơ sở quan trọng nhất của cách tiếp cận hướng đối tượng Đối tượng là một khái niệm, một sự trừu tượng hoá hay một sự vật có nghĩa trong bài toán đang khảo sát Đó chính là các mục mà ta đang nghiên cứu, đang thảo luận về chúng Đối tượng là thực thể của hệ thống, của CSDL và được xác định thông qua định danh của chúng Thông thường các đối tượng được mô tả bởi các danh từ riêng (tên gọi) hoặc được tham chiếu tới trong các mô tả của bài toán hay trong các thảo luận với người sử dụng Có những đối tượng là những thực thể có trong thế giới thực như người, sự vật cụ thể, hoặc là những khái niệm như một công thức, hay khái niệm trừu tượng, v.v Có một số đối tượng được bổ sung vào hệ thống với lý do phục vụ cho việc cài đặt và có thể không có trong thực tế Đối tượng là những thực thể được xác định trong thời gian hệ thống hoạt động
Trong giai đoạn phân tích, việc xác định các đối tượng bằng định danh là rất quan trọng Khi thiết kế, cần lựa chọn cách thể hiện các định danh này, có thể thông qua địa chỉ bộ nhớ, gán số hiệu, hoặc sử dụng tổ hợp giá trị thuộc tính Từ góc độ lập trình, đối tượng được coi là một vùng nhớ trong máy tính, nơi lưu trữ dữ liệu và các hàm thao tác liên quan Các vùng nhớ này độc lập, cho phép đối tượng tham gia vào nhiều chương trình mà không gây ảnh hưởng lẫn nhau.
Hình 2-4 Những khái niệm cơ bản của phương pháp hướng đối tượng
2.2.2 Lớp đối tượng Đối tượng là thể hiện, là một đại biểu của một lớp Lớp là một mô tả về một nhóm các đối tượng có những tính chất (thuộc tính) giống nhau, có chung các hành vi ứng xử (thao tác gần như nhau), có cùng mối liên quan với các đối tượng của các lớp khác và có chung ngữ nghĩa trong hệ thống Lớp chính là cơ chế được sử dụng để phân loại các đối tượng của một hệ thống Lớp thường xuất hiện dưới dạng những danh từ chung trong các tài liệu mô tả bài toán hay trong các thảo luận với người sử dụng Cũng như các đối tượng, lớp có thể là những nhóm thực thể có trong thế giới thực, cũng có những lớp là khái niệm trừu tượng và có những lớp được đưa vào trong thiết kế để phục vụ cho cài đặt hệ thống, v.v
Lớp và mối quan hệ của chúng có thể được thể hiện qua các biểu đồ lớp trong UML Trong biểu đồ lớp, mỗi lớp được mô tả bằng một hình hộp chữ nhật, bao gồm tên lớp, các thuộc tính và phương thức Cấu trúc này giúp người dùng dễ dàng nhận diện và hiểu rõ hơn về các thành phần của lớp, bao gồm tên lớp, tên và thuộc tính, cũng như các phương thức liên quan.
Hình 2-5 Các ký hiệu mô tả lớp trong UML Chúng ta nên đặt tên theo một qui tắc thống nhất như sau:
+ Tên của lớp thì chữ cái đầu của tất cả các từ đều viết hoa, ví dụ: SinhVien, HocSinh, KhachHang, v.v
+ Tên của đối tượng, tên của thuộc tính thì viết hoa chữ cái đầu của các từ trừ từ đầu tiên, ví dụ: hoTen, danhSachSV, v.v
Kế thừa Lớp Quan hệ Đối tượng
+ Tên của hàm (phương thức) viết giống như tên của đối tượng nhưng có thêm cặp ngoặc đơn ‘(‘ và ‘)’, ví dụ: hienThi(), nhapDiem(), v.v
Trong giai đoạn phân tích biểu đồ, một lớp có thể bao gồm tên lớp, tên và thuộc tính, hoặc có thể chứa cả tên, thuộc tính và các phương thức, như thể hiện trong hình 2-5.
2.2.3 Các giá trị và các thuộc tính của đối tượng
Giá trị là một thành phần quan trọng trong dữ liệu, thường biểu hiện dưới dạng số hoặc ký tự Mỗi đối tượng trong một lớp được mô tả bởi các thuộc tính của lớp đó thông qua giá trị của từng đối tượng.
Hình 2-6 Ký hiệu đối tượng trong UML
“Van Ba” và 20 là hai giá trị tương ứng với hai thuộc tính hoTen, tuoi của đối tượng sv1 trong lớp SinhVien
Không nên nhầm lẫn giữa giá trị và đối tượng, vì các đối tượng có định danh riêng, không phải là giá trị Ví dụ, trong một hệ thống quản lý sinh viên, có thể có ba sinh viên cùng tên “Van Ba”, nhưng để xác định duy nhất từng sinh viên, cần phải sử dụng định danh cho mỗi đối tượng.
Giá trị trong lập trình có thể là các kiểu dữ liệu nguyên thuỷ như số và xâu ký tự, hoặc là tập hợp các giá trị nguyên thuỷ khác nhau.
Các thuộc tính quản lý truy cập trong một lớp cho phép bao gói dữ liệu thành phần, giúp che giấu thông tin theo phương pháp lập trình hướng đối tượng Trong ngôn ngữ mô hình hóa UML, chúng ta có thể sử dụng các ký hiệu để mô tả các thuộc tính này một cách rõ ràng.
Ký hiệu ‘+’ trước tên thuộc tính trong hệ thống biểu thị tính công khai (public), cho phép mọi đối tượng truy cập vào dữ liệu này Điều này có nghĩa là tất cả các đối tượng đều có thể nhìn thấy và sử dụng thông tin công khai Trong phần mềm Rose, ký hiệu này được thể hiện như một ổ khóa không bị khóa.
Trong lập trình, ký hiệu ‘#’ trước tên thuộc tính hoặc hàm chỉ định rằng chúng được bảo vệ (protected), chỉ những đối tượng có quan hệ kế thừa mới có thể truy cập Trong phần mềm Rose, ký hiệu này được biểu thị bằng hình ảnh ổ khóa có chìa bên cạnh.
Trong lập trình, ký hiệu ‘-’ trước tên thuộc tính chỉ ra rằng thuộc tính đó là riêng tư (private), chỉ các đối tượng trong cùng lớp mới có thể truy cập Trong phần mềm Rose, ký hiệu này được thể hiện bằng hình ảnh ổ khóa bị khóa, không có chìa khóa bên cạnh.
Trong trường hợp không sử dụng một trong ba ký hiệu truy cập, hệ thống sẽ áp dụng thuộc tính quản lý truy cập mặc định Các ngôn ngữ lập trình khác nhau có quy định khác nhau về thuộc tính này; ví dụ, trong C++, thuộc tính mặc định trong lớp được xác định là private, trong khi Java quy định thuộc tính có phạm vi rộng hơn private Ví dụ, một đối tượng sinh viên có thể được khai báo như sau: sv1: SinhVien hoTen = "Van Ba", tuoi = 20.
Những thuộc tính trên thiết lập quyền truy cập cho mọi đối tượng trong các lớp, các gói, các hệ thống con của hệ thống phần mềm [2, 3]
2.2.4 Các thao tác và phương thức
Các mối quan hệ giữa các lớp
Hệ thống hướng đối tượng bao gồm các đối tượng tương tác để thực hiện nhiệm vụ cụ thể Quan hệ giữa các lớp đối tượng thể hiện mối liên quan về thuộc tính và thao tác trong hệ thống, được mô tả qua biểu đồ lớp Có năm quan hệ cơ bản giữa các lớp trong hệ thống hướng đối tượng.
Quan hệ tổng quát hóa, kế thừa,
Để nắm bắt rõ hơn về các mối quan hệ trong hệ thống, trước tiên, chúng ta cần phân biệt các mối quan hệ giữa các lớp và các đối tượng với nhau.
2.3.1 Sự liên kết và kết hợp giữa các đối tượng
Liên kết là sự kết nối vật lý hoặc logic giữa các đối tượng Phần lớn liên kết thường diễn ra giữa hai đối tượng, nhưng cũng tồn tại các liên kết giữa ba hoặc nhiều hơn ba đối tượng Tuy nhiên, hầu hết các ngôn ngữ lập trình hiện nay chỉ hỗ trợ các phép toán liên kết tối đa là ba ngôi.
Một sự kết hợp mô tả nhóm các liên kết có cấu trúc và ngữ nghĩa tương đồng Liên kết được xem là biểu hiện của lớp, và cả liên kết lẫn sự kết hợp thường xuất hiện dưới dạng động từ trong các tài liệu mô tả bài toán ứng dụng.
Hình 2-7 mô tả các ký hiệu cho quan hệ liên kết và kết hợp
Hình 2-7 (a) Liên kết giữa các đối tượng
Hai đối tượng trong lớp SanBay, Nội Bài và Gia Lâm, liên kết với đối tượng Hà Nội thuộc lớp TinhThanh thông qua quan hệ phục vụ Quan hệ này được thể hiện bằng đoạn thẳng nối giữa chúng và có nhãn tương ứng, thường là các động từ Để biểu diễn quan hệ một chiều, mũi tên sẽ được sử dụng để chỉ rõ hướng của quan hệ.
Hình 2-7 (b) Quan hệ kết hợp giữa các lớp
Khi mô hình không có sự nhập nhằng, tên của quan hệ kết hợp là tùy chọn Sự nhập nhằng xảy ra khi có nhiều quan hệ kết hợp giữa hai lớp, ví dụ như giữa lớp này và lớp khác.
Nhân viên và công ty có hai mối quan hệ làm việc và cổ phần với nhau Khi tồn tại nhiều mối quan hệ như vậy, cần gán tên cho mỗi đường nối hoặc tên vai trò ở mỗi đầu của mối quan hệ để tránh sự nhầm lẫn.
Hình 2-7 (c) Quan hệ kết hợp giữa các lớp
Lưu ý rằng liên kết không nên bị nhầm lẫn với giá trị; giá trị là dữ liệu nguyên thuỷ như số liệu hoặc chuỗi ký tự, trong khi liên kết thể hiện mối quan hệ giữa hai đối tượng Trong giai đoạn phân tích, cần mô hình hóa và xác định tất cả các tham chiếu đến các đối tượng thông qua các liên kết để phục vụ cho quá trình này.
NoiBai: SanBay maSo = HN1 tenGoi = Sân bay quốc tế
GiaLam: SanBay maSo = HN2 tenGoi = Sân bay nội địa
HaNoi: TinhThanh tenGoi = Thu đô Hà Nội soDan = 5000000 phục vụ phục vụ
Trong giai đoạn thiết kế, chúng ta có thể lựa chọn cấu trúc con trỏ, khóa ngoại hoặc các phương pháp khác để cài đặt các quan hệ kết hợp và nhận diện các nhóm liên kết tương tự Ví dụ, mô hình phân tích ở hình 2-7 (b) đã được phát triển sang giai đoạn thiết kế với các cấu trúc phù hợp.
Hình 2-8 Mô hình thiết kế các lớp
Lớp TinhThanh có thể được mở rộng với thuộc tính cacSanBay, có thể là danh sách, cấu trúc mảng hoặc con trỏ Ngoài ra, một cách thiết kế khác là bổ sung thuộc tính oTinhThanh vào lớp SanBay thay vì vào lớp TinhThanh.
Quan hệ kết hợp thường có tính hai chiều, với một đối tượng kết hợp với một số đối tượng thuộc lớp khác và ngược lại Để xác định số lượng đối tượng tham gia vào mỗi đầu của mối quan hệ, khái niệm bội số được sử dụng Bội số xác định số lượng các thể hiện của một lớp trong quan hệ với lớp khác, và cần phân biệt giữa bội số và lực lượng Bội số là ràng buộc về kích cỡ của một tập hợp, trong khi lực lượng chỉ đơn giản là số phần tử trong tập hợp đó Do đó, bội số là sự ràng buộc về lực lượng của các phần tử trong lớp tham gia vào quan hệ đã được xác định trước.
Trong UML các bội số được biểu diễn như sau:
Chính xác 1 (nếu không nhập nhằng có thể không điền số 1) Nhiều (không hoặc nhiều)
Số lượng được xác định giữa số n và k (≥ 0)
Số lượng được xác định bởi số n, với n ≥ 0 Để phân biệt chiều của quan hệ kết hợp, có thể sử dụng mũi tên để chỉ hướng kết hợp.
Hình 2-9 Quan hệ kết hợp hai chiều giữa hai lớp
Nguoi 1 * sở hữu của có
Mỗi người trong lớp Người có thể sở hữu nhiều ô tô thuộc lớp Ô tô, và mỗi ô tô phải thuộc sở hữu của ít nhất một người trong lớp Người.
2.3.3 Các vai trò trong quan hệ
Vai trò là tên gọi một nhiệm vụ, thường được biểu thị bằng danh từ, gán cho một đầu của quan hệ kết hợp Hình 2-10 minh họa hai lớp SanBay và CacChuyenBay có mối quan hệ với nhau Một sân bay có thể vừa là điểm đến của một chuyến bay, vừa là điểm xuất phát của chuyến bay khác Ngược lại, mỗi chuyến bay luôn phải khởi hành từ một sân bay và đến một sân bay khác.
Hình 2-10 Vai trò trong các quan hệ kết hợp
Khi mô hình không có sự nhập nhằng, tên của vai trò là tùy chọn Sự nhập nhằng xuất hiện khi giữa hai lớp có nhiều quan hệ hoặc khi một lớp có quan hệ với chính nó (quan hệ đệ quy) Chẳng hạn, một người có thể là con của hai người (cha-mẹ), và hai cha-mẹ lại có thể có nhiều con, như được mô tả trong hình 2-11.
Hình 2-11 Vai trò trong các quan hệ kết hợp
Các gói
Để hiểu các hệ thống lớn và phức tạp với nhiều lớp đối tượng, chúng ta cần chia chúng thành các nhóm gọi là gói Gói là tập hợp các phần tử của mô hình, bao gồm các lớp, mối quan hệ và các gói nhỏ hơn Cách tổ chức hệ thống thành các gói giúp phân hoạch mô hình thành các đơn vị nhỏ hơn, từ đó dễ hiểu và dễ quản lý hơn Trong UML, gói được mô tả với tên gói và có thể bao gồm các lớp và gói nhỏ khác, được ký hiệu theo hình thức cụ thể.
Hình 2-20 Gói các lớp trong UML
Khi phân chia các lớp thành gói, chúng ta dựa vào các lớp chính, mối quan hệ và chức năng chủ yếu Phân chia này giúp tổ chức hệ thống thành các phân hệ tương ứng với cấu trúc thực tế Ví dụ, hệ thống quản lý thư viện có thể được chia thành bốn gói: gói giao diện, gói nghiệp vụ, gói CSDL và gói tiện ích.
Gói giao diện (UI – User Interface) bao gồm các lớp giao diện với người dùng, cho phép quan sát và truy cập dữ liệu Các đối tượng trong gói này hỗ trợ thực hiện các thao tác trên các đối tượng tác nghiệp để truy vấn hoặc nhập dữ liệu.
Gói nghiệp vụ (Business Package): chứa các lớp thực thể thuộc lĩnh vực bài toán ứng dụng
Gói CSDL: chứa các lớp dịch vị cho các lớp ở gói tác nghiệp trong việc tổ chức, quản lý và lưu trữ dữ liệu
Gói tiện ích: chứa các lớp dịch vụ cho các gói khác của hệ thống
Các gói của một hệ thống thường có mối quan hệ với nhau, như quan hệ phụ thuộc
Hình 2-21 Tổ chức các gói của hệ thống thư viện
Các qui tắc ràng buộc và suy diễn
Trong mô hình hóa hệ thống bằng UML, ngôn ngữ ràng buộc đối tượng OCL được sử dụng để mô tả chính xác các thành phần của hệ thống và các ràng buộc giữa các mối quan hệ Điều này giúp giới hạn phạm vi của mô hình hệ thống phù hợp với các điều kiện ràng buộc thực tế.
Trong UML có hai qui tắc chính:
1 Qui tắc ràng buộc được sử dụng để giới hạn phạm vi của mô hình, ví dụ các qui tắc hạn chế, qui định rõ phạm trù của các mối quan hệ như kết hợp, kế thừa hay khả năng nạp chồng trong các lớp
2 Qui tắc suy dẫn chỉ ra cách các sự vật có thể suy dần được từ một số các thuộc tính khác, ví dụ tuổi của một người có thể suy ra được từ ngày / tháng / năm hiện thời trừ đi ngày / tháng / năm sinh
Các quy tắc ràng buộc và suy dẫn thường được biểu thị bằng cặp dấu ngoặc '{' và '}' bên cạnh các phần tử của mô hình, bao gồm các thuộc tính và mối quan hệ cần tuân theo.
1/ Khi mô tả mối quan hệ giữa hai lớp DangPhai và ChinhTriGia, ta có thể sử dụng qui tắc ràng buộc để khống chế các đối tượng tham gia vào các quan hệ đó Ví dụ, trong các đảng phái chính trị có qui định rằng lãnh tụ của một đảng phải là đảng viên của chính đảng đó Khi đó quan hệ “Chủ tịch của” một đảng phải là tập con {Subset} của quan hệ “đảng viên của” đảng đó và được mô tả trong UML như hình 2-
Hình 2-22 (a) Mối ràng buộc giữa hai quan hệ
2/ Các thuộc tính có thể bị khống chế, bị giới hạn trong phạm vi xác định, ví dụ: điều kiện
{0 ≤ mau ≤ 255} chỉ ra rằng thuộc tính mau (màu) có giá trị trong phạm vi các số nguyên từ 0 đến 255
3/ Một số thuộc tính có thể được suy dẫn từ những thuộc tính khác Ví dụ khi thiết kế lớp SanPham có thuộc tính giaBan và giaSanXuat Trong kinh doanh ta có thể xác định được ngay cách tính lợi nhuận loiNhuan = giaBan – giaSanXuat Cách tính và những qui định trên có thể mô tả như hình 2-22 (b)
Hình 2-22 (b) Qui tắc suy dẫn trong OCL
Trong hình trên, ký hiệu “/” biểu thị rằng thuộc tính loiNhuan được suy dẫn từ quy tắc gắn liền với lớp SanPham.
Quan hệ tổng quát hoá chỉ áp dụng cho các qui tắc hạn chế và không thể áp dụng cho qui tắc suy dẫn Điều này cho thấy rằng các qui tắc hạn chế có thể được nạp chồng, tách rời, hoặc tổng quát hoá hoàn toàn hoặc một phần.
Có 9 quy tắc hạn chế có thể được biểu diễn bằng các biểu thức sử dụng toán tử ‘.’, tương tự như trong các ngôn ngữ lập trình hướng đối tượng.
HopDongBaoHiem.soNguoiMuaBH > 0 Oto.NguoiLai.bangLaiXe = True
Tóm lại, việc phân tích và thiết kế hướng đối tượng bằng UML bao gồm việc xác định các yêu cầu và thành phần của hệ thống để tạo ra các biểu đồ mô tả yêu cầu, khái niệm và kiến trúc của hệ thống Quá trình này được thể hiện qua các bước như trong hình 2-23.
Hình 2-23 Qui trình xây dựng các biểu đồ UML trong phân tích, thiết kế hệ thống
Biểu đồ ca sử dụng Biểu đồ trình tự Biểu đồ cộng tác
Biểu đồ trạng thái Biểu đồ lớp Biểu đồ hành động
Biểu đồ thành phần Biểu đồ triển khai
Chi tiết về các biểu đồ và cách xây dựng chúng như thế nào sẽ được đề cập ở các chương sau.
BIỂU ĐỒ CA SỬ DỤNG PHÂN TÍCH CÁC NHU CẦU CỦA HỆ THỐNG
Định nghĩa bài toán
Bước đầu tiên trong quá trình phát triển hệ thống là xác định các nhu cầu của bài toán Để sáng tạo ra một hệ thống mới, người phát triển cần làm quen và hiểu rõ chuyên môn cũng như quy trình nghiệp vụ mà hệ thống phải đáp ứng Việc tìm hiểu và tập hợp các nhu cầu của hệ thống là rất quan trọng, vì "nhu cầu là mẹ của mọi sáng tạo".
Bài toán phân tích và thiết kế hệ thống phần mềm hướng đối tượng được định nghĩa như sau: chúng ta sẽ xác định các yêu cầu và cấu trúc của hệ thống nhằm tối ưu hóa quy trình phát triển phần mềm.
Một công ty đang tìm cách xây dựng một hệ thống phần mềm nhằm phục vụ và quản lý các hoạt động kinh doanh và bán hàng Hệ thống này sẽ hỗ trợ công ty trong việc quản lý nhiều điểm bán hàng đầu cuối một cách hiệu quả.
Hệ thống POST (Point Of Sale Terminal) được áp dụng tại các cửa hàng siêu thị, giúp ghi nhận hoạt động bán hàng và xử lý thanh toán cho khách hàng mua lẻ Ngoài việc hỗ trợ thanh toán, hệ thống còn cho phép Giám đốc Công ty theo dõi các 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ừ đó đưa ra quyết định kinh doanh hiệu quả Mỗi cửa hàng đều trang bị các thiết bị phần cứng cần thiết như máy tính, máy đọc mã vạch và phần mềm hệ thống.
Hệ thống bán hàng (HBH) là phần mềm thiết kế để ghi lại các phiên bán hàng và xử lý thanh toán nhanh chóng cho khách hàng, chủ yếu phục vụ cho việc mua sắm lẻ Khi xây dựng một hệ thống mới, mục tiêu thường là thay thế hệ thống cũ đã bộc lộ nhiều hạn chế Do đó, việc khảo sát và đánh giá nhu cầu từ hệ thống cũ là bước khởi đầu quan trọng trong quá trình phát triển hệ thống mới.
Tăng cường hiệu quả bán hàng thông qua tự động hóa, ghi nhận thông tin sản phẩm như loại, mô tả, số lượng và giá bán Đảm bảo đáp ứng đầy đủ mọi yêu cầu của khách hàng một cách nhanh chóng và chính xác.
Thanh toán nhanh với khách hàng bằng các phương thức: tiền mặt, thẻ tín dụng (Credit Card), hay séc (Check),
Phân tích, xử lý các kết quả bán hàng nhanh và chính xác để hỗ trợ quyết định trong các hoạt động kinh doanh,
Tự động kiểm kê hàng hóa trong kho giúp theo dõi mặt hàng bán chạy và tồn kho, từ đó đưa ra quyết định kịp thời cho hoạt động kinh doanh.
Tóm lại, hệ thống xây dựng nhằm tự động hoá các hoạt động kinh doanh, phục vụ khách hàng nhanh hơn, tốt hơn và rẻ hơn
Các chức năng, nhiệm vụ của hệ thống
Chức năng của hệ thống là những gì mà hệ thống được yêu cầu thực hiện
Nhiệm vụ “X” sẽ là chức năng của hệ thống nếu trong mô tả bài toán có mệnh đề dạng: Hệ thống phải thực hiện X
Trong giai đoạn này, các tính chất và yêu cầu về chất lượng hệ thống như hiệu quả và an toàn chưa được xem xét, tức là chưa đề cập đến các đặc tính phi chức năng của hệ thống.
Hệ thống có thể phân loại các chức năng thành những lĩnh vực chức năng khác nhau hoặc theo mức độ ưu tiên để tránh sự lẫn lộn Các chức năng này được chia thành hai loại chính.
Chức năng hiển thị là rất quan trọng, cho phép người dùng theo dõi hoạt động của hệ thống một cách rõ ràng Khi người bán nhập các mặt hàng khách đã chọn vào giỏ hàng, tất cả thông tin liên quan như tên sản phẩm, số lượng và giá bán sẽ được hiển thị trên màn hình Điều này giúp khách hàng dễ dàng theo dõi và nắm bắt thông tin một cách minh bạch.
Những chức năng ẩn trong hệ thống thường bao gồm các nhiệm vụ kỹ thuật mà người sử dụng không thể theo dõi, như tổ chức lưu trữ và xử lý dữ liệu nhằm đảm bảo tính bền vững của cơ sở dữ liệu Ví dụ, sau mỗi phiên bán hàng, khi khách hàng đã thanh toán đầy đủ, hệ thống bán hàng HBH cần phải cập nhật lại số lượng hàng hóa đã bán, nhưng những hoạt động này không được người sử dụng theo dõi.
Một số chức năng tùy chọn có thể được bổ sung để nâng cao tính thân thiện và tiện dụng của hệ thống, mà không làm ảnh hưởng đến giá trị cũng như các chức năng khác của nó.
Hệ thống cần được phân chia thành các nhóm chức năng có mối liên hệ chặt chẽ với nhau Việc phân loại này sẽ hỗ trợ trong việc chia nhỏ hệ thống thành các gói và hệ thống con trong quá trình phân tích và thiết kế.
Hệ thống HBH bao gồm hai nhóm chức năng chính: chức năng bán hàng, được xem là các chức năng cơ sở, và chức năng thanh toán.
Dựa trên kết quả khảo sát bài toán bán hàng, nghiên cứu tài liệu và sổ sách, cùng với việc trao đổi với người bán hàng và khách hàng, chúng tôi đã xác định các chức năng chính của hệ thống.
Qui tắc # Chức năng Loại
R1.1 Ghi nhận các mặt hàng ở trong giỏ hàng mà khách hàng đã chọn Hiển R1.2 Tính tổng số tiền bán cho khách hàng đang mua Hiển
Phân tích và đặc tả các yêu cầu hệ thống
Khái niệm ca sử dụng (Use Case) được Ivan Jacobson giới thiệu vào năm 1994, nhằm mục đích mô tả các dịch vụ mà hệ thống cung cấp cho khách hàng Nó cũng xác định mối quan hệ tương tác giữa hệ thống phần mềm và người sử dụng trong bối cảnh nghiệp vụ.
Mô tả các hoạt động của hệ thống từ quan điểm của các tác nhân (Actor) là một cách hình thức để nêu rõ yêu cầu của hệ thống, đồng thời trả lời các câu hỏi liên quan đến chức năng và nhiệm vụ của nó.
Hệ thống phải làm cái gì (What ?)
Quá trình ca sử dụng mô tả các bước từ khởi đầu đến kết thúc, bao gồm chuỗi thao tác và giao dịch cần thiết để tạo ra giá trị hoặc thông tin theo yêu cầu của tổ chức hoặc cá nhân.
Ca sử dụng được ký hiệu là:
Hình 3-1 Ký hiệu của ca sử dụng
"Hoạt động" trong hệ thống đề cập đến các chức năng và nhiệm vụ, thường được diễn đạt qua các động từ hoặc mệnh đề động từ đơn như bán hàng, thanh toán, và khởi động hệ thống.
Những ca sử dụng phức tạp sẽ được mô tả chi tiết thông qua các kịch bản
Mục tiêu của ca sử dụng trong cả quá trình phát triển phần mềm:
Mô tả yêu cầu chức năng của hệ thống là kết quả từ quá trình khảo sát và nghiên cứu các yêu cầu của bài toán, cũng như những thỏa thuận giữa khách hàng, người sử dụng hệ thống và nhà phát triển phần mềm.
Làm cơ sở để người phân tích viên hiểu, người thiết kế xây dựng các kiến trúc, người lập trình cài đặt các chức năng của hệ thống,
Cung cấp các cơ sở để kiểm duyệt, thử nghiệm hệ thống
Các ca sử dụng đóng vai trò quan trọng trong quá trình phát triển phần mềm, vì tất cả các giai đoạn phân tích và thiết kế đều dựa vào chúng Việc mô hình hóa hệ thống bằng cách sử dụng ca sử dụng là một phương pháp hiệu quả với UML Hình 3-2 minh họa những ai cần đến ca sử dụng và mục đích của chúng Người sử dụng cần nêu rõ yêu cầu hệ thống, phân tích viên phải hiểu công việc của hệ thống, kiến trúc sư phải xác định các thành phần thực hiện ca sử dụng, lập trình viên thực hiện cài đặt, và cuối cùng, nhân viên kiểm tra hệ thống dựa trên các ca sử dụng đã được xác định.
Hình 3-2 Vai trò của ca sử dụng trong quá trình phát triển phân mềm
Tác nhân ngoài, hay đơn giản là tác nhân, là những thực thể bên ngoài tương tác với hệ thống, bao gồm con người, vật thể, thiết bị hoặc các hệ thống khác Chúng có vai trò quan trọng trong việc trao đổi thông tin với hệ thống Tác nhân đại diện cho cá nhân hoặc bộ phận trong tổ chức, với mong muốn nhận thông tin (dữ liệu) hoặc câu trả lời từ các trường hợp sử dụng tương ứng.
Ví dụ: Khách mua hàng, người bán hàng là hai tác nhân của HBH
Ký hiệu của tác nhân là hình nhân cùng với tên gọi như hình 3-3
Hình 3-3 Ký hiệu tác nhân Khách hàng
Tên gọi của tác nhân được mô tả bằng các danh từ (chung) và thường phải nêu được vai trò của nó đối với hệ thống
Tác nhân tương tác với hệ thống thông qua việc sử dụng các dịch vụ, diễn ra qua các ca sử dụng và việc trao đổi thông điệp Qua đó, tác nhân có thể cung cấp hoặc sử dụng thông tin của hệ thống thông qua các ca sử dụng này.
Người sử dụng Người kiểm tra
Người thiết kế Lập trình viên
Diễn đạt yêu cầu Kiểm tra
Hình 3-5 Tác nhân Khách hàng tương tác với ca sử dụng Thanh toán
Trong mỗi hệ thống, các tác nhân như khách hàng, người sử dụng, người quản lý và người phục vụ đóng vai trò quan trọng Một ca sử dụng thường được khởi động bởi hoặc phục vụ cho một hoặc nhiều tác nhân này.
3.2.3 Xác định các ca sử dụng và các tác nhân
Việc xác định và hiểu rõ các yêu cầu hệ thống thường rất khó khăn do khối lượng thông tin lớn, lộn xộn và thiếu cấu trúc Khái niệm ca sử dụng được giới thiệu để thể hiện các yêu cầu từ phía người sử dụng, nhấn mạnh rằng hệ thống được xây dựng chủ yếu để phục vụ nhu cầu của người dùng và khách hàng.
Các tác nhân và ca sử dụng trong một hệ thống có mối quan hệ chặt chẽ, với mỗi tác nhân liên quan đến ít nhất một ca sử dụng và mỗi ca sử dụng phục vụ cho một hoặc nhiều tác nhân Mối quan hệ này giúp mô tả tổng thể về hệ thống và xác định các yêu cầu cần thiết Do đó, việc xác định đầy đủ và chính xác các tác nhân và ca sử dụng là rất quan trọng trong quá trình xây dựng hệ thống.
Xác định các tác nhân
Tác nhân là một phần bên ngoài của hệ thống, nhưng lại có sự hợp tác chặt chẽ với nó Đây là đối tượng mà hệ thống phục vụ hoặc cần thiết để cung cấp dữ liệu.
Do đó, nhiệm vụ trước tiên của người phân tích là xác định các tác nhân
Một trong các kỹ thuật hỗ trợ để xác định các tác nhân là dựa trên các câu trả lời những câu hỏi sau:
Ai sẽ sử dụng các chức năng chính của hệ thống?
Ai cần sự hỗ trợ của hệ thống để thực hiện các công việc hàng ngày?
Ai quản trị, bảo dưỡng để đảm bảo cho hệ thống hoạt động thường xuyên?
Hệ thống quản lý, sử dụng những thiết bị nào?
Hệ thống cần tương tác với những bộ phận, hệ thống nào khác?
Ai hay cái gì quan tâm đến kết quả xử lý của hệ thống?
Xác định các ca sử dụng
Bước tiếp theo là xác định các ca sử dụng dựa trên tài liệu mô tả yêu cầu và các tác nhân liên quan Có hai phương pháp chính hỗ trợ quá trình này trong việc xác định các ca sử dụng hiệu quả.
1 Phương pháp thứ nhất là dựa vào các tác nhân: a Xác định những tác nhân liên quan đến một hệ thống hoặc đến một tổ chức, nghĩa là tìm và xác định những tác nhân là NSD hay những hệ thống khác tương tác với hệ thống cần xây dựng b Với mỗi tác nhân, tìm những tiến trình (chức năng) được khởi đầu, hay giúp các tác nhân thực hiện, giao tiếp / tương tác với hệ thống
2 Phương pháp thứ hai để tìm các ca sử dụng là dựa vào các sự kiện a Xác định những sự kiện bên ngoài có tác động đến hệ thống hay hệ thống phải trả lời b Tìm mối liên quan giữa các sự kiện và các ca sử dụng
Tương tự như trên, hãy trả lời những câu hỏi sau đây để tìm ra các ca sử dụng:
1 Nhiệm vụ chính của các tác nhân là gì?
2 Tác nhân cần phải đọc, ghi, sửa đổi, cập nhật, hay lưu trữ thông tin hay không?
3 Những thay đổi bên ngoài hệ thống thì tác nhân có cần phải thông báo cho hệ thống hay không?
4 Những tác nhân nào cần được thông báo về những thay đổi của hệ thống?
5 Hệ thống cần có những đầu vào/ra nào?, từ đâu và đến đâu?
Dựa vào các phương pháp nêu trên, chúng ta hãy xác định các tác nhân và các ca sử dụng của hệ thống HBH
1 Danh sách các tác nhân của HBH:
+ Khách hàng (Customer): là những người được hệ HBH phục vụ, là khách hàng
+ Người bán hàng (Cashier): những người cần sử dụng chức năng bán hàng của hệ thống để thực hiện nhiệm vụ của mình
+ Người quản lý (Manager): những người được phép khởi động (Start Up) hay kết thúc cả hệ thống (Shut Down) tại các điểm bán hàng đầu cuối
+ Người quản trị hệ thống (System Administrator): có thể bổ sung, thay đổi những NSD
2 Danh sách các ca sử dụng của HBH
Biểu đồ ca sử dụng
Biểu đồ ca sử dụng chỉ ra mối quan hệ giữa các tác nhân và các ca sử dụng trong hệ thống
Mỗi ca sử dụng cần phải biểu diễn trọn vẹn một giao dịch giữa NSD và hệ thống
Mối quan hệ giữa các ca sử dụng
Giữa các ca sử dụng có ba quan hệ chính: quan hệ “mở rộng”, quan hệ “sử dụng” và quan hệ theo nhóm hay theo “gói”
Khi phát triển các ca sử dụng, chúng ta nhận thấy rằng một số ca sử dụng có thể được tái sử dụng trong các chức năng khác Trong những tình huống này, việc tạo ra một ca sử dụng mới để mở rộng một hoặc nhiều ca sử dụng đã được xác định trước là cần thiết.
Ca sử dụng mở rộng là sự phát triển từ các ca sử dụng cũ, thể hiện mối quan hệ giữa chúng thông qua ký hiệu Mối quan hệ này được mô tả tương tự như quan hệ tổng quát hóa, giúp làm rõ cách thức mở rộng và cải tiến các ca sử dụng ban đầu.
Hình 3-6 Mối quan hệ mở rộng giữa các ca sử dụng Khách hàng có thể rút tiền theo nhiều cách khác nhau, trong đó cách rút nhanh
Ca sử dụng B mở rộng A nếu: B là biến thể của A và nó chứa thêm một số sự kiện cho những điều kiện nào đó
Khi một số ca sử dụng có hành vi chung, chúng có thể được xây dựng thành một ca sử dụng mới để áp dụng cho các trường hợp khác Mối quan hệ này được gọi là mối quan hệ sử dụng, trong đó một ca sử dụng dựa vào một ca sử dụng khác, thể hiện sự chuyên biệt hóa của ca sử dụng cơ sở.
Giống như mối quan hệ mở rộng, mối quan hệ sử dụng cũng sử dụng ký hiệu tổng quát hoá để thể hiện với nhãn Ví dụ:
Để thực hiện ca sử dụng Thanh toán, cần gọi đến ca sử dụng Thanh toán tiền mặt khi khách hàng chọn phương thức trả bằng tiền mặt.
Trong UML 1.3, quan hệ sử dụng được gọi là quan hệ gộp vào
← Ca sử dụng cơ sở
← Ca sử dụng mở rộng
3 Mối quan hệ gộp nhóm
Khi có nhiều ca sử dụng tương tự hoặc liên quan đến nhau, việc nhóm chúng thành các gói chức năng là rất hiệu quả Ví dụ, trong hệ thống HBH, các ca sử dụng có thể được phân loại thành các gói như Bán hàng, Thanh toán và Quản lý hệ thống.
Trong UML, khái niệm mẫu rập khuôn (stereotype) được thể hiện bằng một xâu và được đặt trong cặp >, nhằm phân nhóm các thành phần của mô hình hệ thống Ví dụ, đối với hai ca sử dụng UC A, UC.
B, ta có thể tạo ra hai mẫu rập khuôn tương ứng , Stereotype không được sử dụng thường xuyên cho các ca sử dụng, nó được sử dụng cho lớp hay cho các mối quan hệ Ví dụ, là một mẫu rập khuôn trong UML và khi một lớp được chỉ ra trong biểu tượng stereotype: có dạng: thì nó được xem là lớp có kiểu Actor
Sau khi xác định các ca sử dụng cho hệ thống, cần kiểm tra xem tất cả đã được phát hiện đầy đủ hay chưa Công việc này được thực hiện thông qua việc trả lời các câu hỏi liên quan.
Mỗi yêu cầu chức năng của hệ thống cần phải được phản ánh trong ít nhất một ca sử dụng Những chức năng không được mô tả trong các ca sử dụng sẽ không được triển khai trong tương lai.
Các mối tương tác giữa các tác nhân và hệ thống đã xác định hết chưa?
Tác nhân cung cấp những gì cho hệ thống?
Tác nhân nhận được những gì từ hệ thống? Đã nhận biết được tất cả các hệ thống bên ngoài có tương tác với hệ thống chưa?
Những thông tin nào mà hệ thống ngoài gửi tới hoặc nhận được từ hệ thống?
Một lần nữa cần duyệt lại xem đã xác định đầy đủ, chính xác các tác nhân, ca sử dụng và mối quan hệ của chúng
Xây dựng biểu đồ ca sử dụng cho hệ HBH
Trước khi xây dựng biểu đồ ca sử dụng chúng ta cần lưu ý:
Mỗi ca sử dụng đều có ít nhất một tác nhân kích hoạt, thể hiện mối quan hệ giao tiếp trực tiếp hoặc gián tiếp giữa tác nhân và ca sử dụng.
Ca sử dụng cung cấp thông tin thiết yếu cho tác nhân, trong khi đó, tác nhân lại cung cấp dữ liệu đầu vào cần thiết để ca sử dụng thực hiện các nhiệm vụ của mình.
Từ những kết quả phân tích ở trên, đến đây chúng ta có thể xây dựng biểu đồ ca sử dụng cho HBH như sau:
Hình 3-8 Biểu đồ ca sử dụng của hệ thống HBH Một số điểm cần chú ý khi xây dựng biểu đồ ca sử dụng:
Các tác nhân trong hệ thống không có mối quan hệ trực tiếp với nhau Chúng nằm ngoài hệ thống, do đó, việc giao tiếp giữa các tác nhân cũng cần được xây dựng bên ngoài hệ thống này.
Giữa các ca sử dụng không có quan hệ trực tiếp, trừ mối quan hệ mở rộng
hoặc như đã nói ở trên
Mỗi ca sử dụng cần có một tác nhân khởi động hoặc phục vụ cho một tác nhân khác, trừ trường hợp các ca sử dụng mở rộng hoặc ca sử dụng theo quan hệ sử dụng.
Mỗi phần tử trong biểu đồ ca sử dụng, bao gồm ca sử dụng và tác nhân, có thể được mô tả chi tiết trong phần đặc tả (Documentation của Rose) hoặc trong một tệp riêng biệt, sau đó gán tương ứng cho phần tử đó trong mô hình ca sử dụng.
Khi làm việc với hệ thống lớn và phức tạp, việc phân chia các ca sử dụng thành các gói là cần thiết Điều này giúp nhóm các ca sử dụng và các tác nhân có liên quan, từ đó tạo ra các hệ thống con hiệu quả hơn.
Bộ phận kiểm duyệt thẻ
Bán hàng Đăng nhập hệ thống
Bộ phận kiểm duyệt séc
Người quản lý Quản trị hệ thống
Thêm / Loại bỏ NSD Đóng hệ thống
PHÂN TÍCH HỆ THỐNG – MÔ HÌNH KHÁI NIỆM VÀ BIỂU ĐỒ LỚP
Mô hình khái niệm – mô hình đối tượng
Phương pháp hướng đối tượng tập trung vào việc phân tách hệ thống thành các đối tượng, giúp xác định rõ ràng các khái niệm và sự vật mà chúng ta hiểu biết Mô hình khái niệm đóng vai trò quan trọng trong việc biểu diễn các khái niệm và thực thể liên quan đến phạm vi bài toán.
Các khái niệm cơ bản
Một khái niệm có thể được hiểu là một ý tưởng, sự vật, hoặc đối tượng Khi xem xét một cách sâu sắc hơn, khái niệm này có thể được phân tích qua nhiều phương diện khác nhau.
Ký hiệu: những từ hay hình ảnh biểu diễn cho một khái niệm Định nghĩa về một khái niệm và
Sự mở rộng bao gồm tập các ví dụ hoặc các thể hiện của một khái niệm
Sự khác biệt chính giữa phân tích hướng đối tượng và phân tích có cấu trúc là phân rã hệ thống thành các khái niệm (đối tượng) thay vì các chức năng Nhiệm vụ trọng tâm của phân tích hướng đối tượng là xác định các lớp đối tượng và mối quan hệ giữa chúng trong hệ thống, từ đó quyết định thiết kế và cài đặt nhằm thực hiện các chức năng của bài toán.
Trong UML, lớp được định nghĩa là một mô tả về tập hợp các đối tượng có chung thuộc tính, phương thức hành động và mối quan hệ, đồng thời có sự tương đồng về ngữ nghĩa Các khái niệm như thuộc tính, phương thức, thao tác và mối quan hệ sẽ dần được làm rõ trong quá trình phát triển hệ thống.
Trong hệ thống, các đối tượng cần được phân biệt rõ ràng, ngay cả khi chúng có cùng tập các tính chất như tên, tuổi hay điểm thi Để phân biệt các đối tượng này, định danh (Identity) là thuộc tính quan trọng nhất Mỗi đối tượng đều có một định danh riêng, được thiết lập khi đối tượng được tạo ra trong hệ thống, giúp phân biệt chúng với những đối tượng khác có các đặc điểm tương tự.
Tính bền vững của đối tượng trong hệ thống được thể hiện qua thời gian sống của chúng, điều này tạo nên bản chất tĩnh cho hệ thống Những đối tượng bền vững sẽ được lưu trữ trong các cơ sở dữ liệu điện tử (CSDL ĐT).
Mỗi đối tượng phải hoặc có thể tương tác với các đối tượng khác, điều này dẫn đến bản chất động của hệ thống
Khi xây dựng mô hình cho hệ thống phần mềm, các khái niệm cần phải đơn giản và dễ hiểu để thuận tiện cho việc trao đổi trong quá trình phát triển Các khái niệm về nghiệp vụ cần được thiết kế lại sao cho phù hợp với quy trình xử lý công việc hiện tại và có khả năng thích ứng với xu hướng phát triển trong tương lai.
Trong UML, mô hình khái niệm của một hệ thống được mô tả bởi biểu đồ lớp
Vấn đề quan trọng ở giai đoạn này là xác định một cách đầy đủ và chính xác các lớp đối tượng cũng như mối quan hệ giữa chúng trong hệ thống cần phát triển.
Quá trình phát triển phần mềm hướng đối tượng sử dụng UML được dẫn dắt bởi các ca sử dụng, do đó, việc xác định các lớp đối tượng chủ yếu dựa vào phân tích các ca sử dụng của hệ thống.
Xác định các lớp đối tượng
Có sáu cách chính để tìm các lớp đối tượng:
Dựa vào văn bản và kịch bản mô tả bài toán, các danh từ có thể được xem như đại biểu của lớp Đồng thời, cần căn cứ vào danh sách phân loại các phạm trù khái niệm để xác định mối quan hệ và cấu trúc giữa các đại biểu này.
(iii) Dựa vào mục đích của các ca sử dụng [10],
(iv) Dựa vào kinh nghiệm và kiến thức của người phân tích,
(v) Dựa vào hồ sơ tài liệu những hệ thống có liên quan,
(vi) Dựa vào ý kiến tham khảo với các chuyên gia hệ thống
Trong quá trình phân tích hệ thống, việc kết hợp các phương pháp là cần thiết để xác định các lớp của nó Bài viết này sẽ tập trung vào ba phương pháp chính để xác định các lớp đối tượng trong phân tích hệ thống.
1 Dựa vào văn bản, kịch bản mô tả bài toán để tìm các lớp ([6], [10]) Ở pha trước, giai đoạn phân tích các yêu cầu của hệ thống đã có các mô tả bài toán, đã xây dựng đặc tả các ca sử dụng và các kịch bản mô tả chi tiết những ca sử dụng phức tạp để hiểu rõ bài toán Các danh từ trong các mô tả văn bản đó có thể là đại biểu của lớp hoặc thuộc tính của lớp Do vậy, có thể 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ụ, gạch chân những danh từ chung trong đoạn văn mô tả hệ HBH:
Công ty cần xây dựng một hệ thống phần mềm để quản lý hoạt động kinh doanh tại các điểm bán hàng đầu cuối, như siêu thị, nhằm ghi nhận doanh thu và xử lý thanh toán cho khách hàng mua lẻ Hệ thống này cũng hỗ trợ giám đốc theo dõi các hoạt động kinh doanh, tự động kiểm kê hàng tồn kho và xác định các mặt hàng bán chạy, từ đó giúp đưa ra quyết định kinh doanh hiệu quả Mỗi điểm bán hàng sẽ được trang 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 phát triển riêng để vận hành.
Không phải tất cả các danh từ được gạch chân trong văn bản mô tả bài toán đều đại diện cho lớp Chẳng hạn, các cụm danh 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ể quan trọng trong hệ thống HBH.
Một số danh từ và cụm danh từ có thể được sử dụng thay thế cho nhau khi mô tả các thực thể có vai trò tương tự trong hệ thống Ví dụ, "hệ thống" và "hệ thống phần mềm" có thể được thay thế bằng từ viết tắt "HBH" Tương tự, "hoạt động bán hàng" và "hoạt động kinh doanh" có thể được gọi là "giao dịch bán hàng" hoặc "phiên bán hàng".
Dựa vào các danh từ và cụm danh từ đã được gạch chân, chúng ta có thể loại bỏ những mục không đại diện cho lớp học Danh sách các đại biểu sẽ phản ánh 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
Tương tự, đối với các kịch bản Ví dụ: xét kịch bản mô tả ca sử dụng “Bán hàng”
Hành động của các tác nhân Hành động của Hệ thống
1 Khách hàng sau khi chọn đủ số hàng cần thiết thì đưa hàng đã chọn đến cho quầy thu tiền
2 Người bán ghi nhận từng mặt hàng Nếu một mặt hàng mua với số lượng nhiều hơn thì người bán nhập vào số lượng đó vào từ bàn phím
3 Xác định giá và các thông tin về sản phẩm được hiển thị
4 Khi đã nhập xong các mặt hàng của khách đã chọn mua thì người bán phải chỉ cho hệ HBH biết là đã kết thúc phiên bán hàng bằng cách nhấn phím Enter hoặc nhấn nút “Kết thúc” phiên bán hàng ( EndSale)
5 Tính và hiển thị tổng số tiền bán hàng
6 Người bán thông báo cho khách hàng biết tổng số tiền phải trả
7 Khách hàng chọn phương thức thanh toán: d) Nếu chọn trả tiền mặt: xem tiếp kịch bản con
(Sub_scenario) Thu tiền mặt e) Nếu trả thẻ tín dụng: xem kịch bản con Thu bằng thẻ tín dụng f) Nếu trả tiền séc: xem kịch bản con Thu bằng
8 Hiển thị số tiền dư phải trả cho khách hàng
9 Kết thúc một phiên giao dịch bán hàng
10 Cập nhật lại các hàng trong cửa hàng
11 Phát sinh phiếu bán hàng (hoá đơn)
12 Người bán trả tiền thừa và đưa phiếu bán hàng cho khách hàng
13 Khách hàng ra khỏi cửa hàng với hàng đã thanh toán
Ngoài những đại biểu lớp đã nêu trên, có thể liệt kê thêm những danh từ là đại biểu lớp trong HBH:
NguoiBan (người bán): đại diện cho người bán, người bán hàng, người thu tiền,
MoTaMatHang (thông tin về mặt hàng): thông tin về sản phẩm, thông tin về mặt hàng, đặc tả sản phẩm, v.v
PhieuBanHang (phiếu bán hàng): phiếu bán hàng, hoá đơn, v.v
2 Dựa vào danh sách phân loại các phạm trù khái niệm ([6], [10])
Ngoài các phương pháp đã đề cập, chúng ta có thể sử dụng danh sách phân loại các phạm trù khái niệm để xác định thêm những đại biểu mới cho hệ thống hoặc loại bỏ những danh từ không thực sự đại diện cho lớp.
Ví dụ: Xét các phạm trù khái niệm (concept category) của hệ thống “bán hàng” và hệ thống “Đặt vé máy bay”
Các phạm trù khái niệm Ví dụ
Các đối tượng vật lý, hay hữu hình Hệ HBH, NguoiBan, KhachHang
Mô tả, đặc tả, tài liệu của sự vật MoTaMatHang
MoTaChuyenBay (mô tả chuyến bay) Địa điểm, nơi, chốn CuaHang
SanBay (sân bay) Các mục trên dòng giao dịch
Các giao dịch (Transaction) PhienBanHang (Sale), ThanhToan
Vai trò của con người NguoiBan, KhachHang
PhiCong Các vật chứa trong container (vật chứa) MatHang
Vật chứa các vật khác (Container of other thing) CuaHang
SanBay Các tổ chức (Organizations) PhòngBánHàng (SaleDepartment)
Các sự kiện (Events) BanHang, ThanhToan
CấtCánh, HạCánh Các danh mục (Catalogs) DanhMucMatHang (ProceductCatalog)
Các bản ghi về tài chính, dòng công việc, hợp đồng,
Trong các phạm trù nêu trên, ta thấy hệ HBH có thêm:
MoTaMatHang (Thông tin về các mặt hàng), và
DanhMucMatHang (Danh mục về các mặt hàng)
Trong hệ thống bán hàng đang phân tích, khái niệm Phiếu bán hàng (Receipt) không cần thiết làm đại biểu cho lớp, vì thông tin trong phiếu bán hàng có thể suy ra từ các khái niệm khác Do đó, việc ghi chép hay báo cáo về phiếu bán hàng không thực sự cần thiết trong mô hình khái niệm này.
Các khái niệm trong hệ thống thông tin quản lý đóng vai trò quan trọng trong việc duy trì hoạt động hiệu quả của hệ thống Chẳng hạn, khi khách hàng có quyền trả lại các mặt hàng kém chất lượng, việc lưu trữ các phiếu bán hàng là cần thiết để làm căn cứ cho việc nhận lại hàng Do đó, trong những tình huống này, phiếu bán hàng cần được đưa vào danh sách các lớp cần xây dựng trong hệ thống.
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 đối tượng:
Những thông tin nào cần phân tích, cần 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, 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
3 Dựa vào mục đích của các ca sử dụng để xác định các lớp đối tượng [10]
Trong quá trình phát triển phần mềm, công việc chính được hướng dẫn bởi ca sử dụng, cụ thể là việc ánh xạ từ biểu đồ ca sử dụng sang biểu đồ lớp Hai phương pháp này tập trung vào việc phân tích các văn bản mô tả ca sử dụng và các phạm trù cơ sở, theo cách tiếp cận mô hình đối tượng hướng danh từ để xác định các lớp.
Một thách thức chung trong cả hai phương pháp là khả năng phát hiện quá nhiều đại biểu lớp cùng lúc, như việc xem mỗi danh từ là một đại biểu Hơn nữa, theo kinh nghiệm của các nhà phân tích sử dụng UML, hai phương pháp này còn gặp phải một số vấn đề trong việc mô hình hóa đối tượng.
Mô tả ca sử dụng chỉ là một kịch bản, thể hiện cách thực hiện để đạt được mục đích cụ thể, không phải là tất cả các khía cạnh Các lớp được xác định theo cách này bị giới hạn bởi mô tả đó, vì một ca sử dụng có thể có nhiều cách diễn đạt khác nhau từ nhiều người khác nhau Điều này dẫn đến việc một thực thể có thể được xác định bởi nhiều tên lớp khác nhau, ví dụ như người mua hàng có thể được gọi là khách hàng, và nhân viên có thể được gọi là cán bộ hay công chức Hệ quả là có quá nhiều danh từ để lựa chọn tên lớp có ý nghĩa trong một hệ thống.
Nhiều phân tích viên thường gặp khó khăn trong việc thống nhất các kiểu phân loại sự vật do sự đa dạng của các phạm trù Sự tồn tại của quá nhiều phạm trù với vai trò khác nhau trong các bộ phận khác nhau gây ra xung đột và cản trở quá trình thỏa thuận Điều này đặt ra thách thức cho các nhà phân tích trong việc xác định những phạm trù chính xác cần được lựa chọn.
Mối quan hệ giữa các lớp đối tượng
Hệ thống luôn là một thể thống nhất, với các phần tử tương tác và hợp tác lẫn nhau Do đó, mô hình khái niệm cần bao gồm các khái niệm khác nhau nhưng phải có sự tương tác Nhiệm vụ của chúng ta là xác định các mối quan hệ này.
Trong chương II, chúng ta đã tìm hiểu về bốn mối quan hệ giữa các lớp Trong giai đoạn phân tích, chúng ta tập trung vào việc phát hiện các mối quan hệ kết hợp và kết nhập giữa các lớp Trong số đó, quan hệ kết hợp là quan trọng nhất, vì nó thể hiện các liên hệ giữa các lớp trong hệ thống.
Trong UML, sự kết hợp (Association) là mối quan hệ giữa hai lớp, xác định cách mà các đối tượng của các lớp liên kết để thực hiện công việc Đối với lớp, thể hiện của nó là các đối tượng, còn đối với mối quan hệ kết hợp, thể hiện là sự liên kết giữa các đối tượng của hai lớp Điều này có nghĩa là các đối tượng trong một lớp chia sẻ mối quan hệ với nhau.
Các đối tượng trong lĩnh vực ứng dụng có thể thiết lập nhiều loại quan hệ khác nhau, do đó, các lớp khái niệm cũng cần phản ánh đầy đủ các loại quan hệ này.
Quan hệ kết hợp giữa hai lớp là sự kết nối vật lý hay khái niệm giữa các đối tượng của hai lớp đó
Chỉ những đối tượng có mối quan hệ kết hợp mới có khả năng cộng tác thông qua các liên kết được thiết lập giữa các lớp.
Booch đã mô tả vai trò của mối liên kết giữa các đối tượng như sau:
Một liên kết thể hiện mối quan hệ giữa hai đối tượng, trong đó một đối tượng phục vụ hoặc điều khiển đối tượng còn lại.
PhienBanHang và ThanhToan là hai lớp có mối quan hệ chặt chẽ trong hệ thống HBH, với mỗi giao dịch thanh toán tương ứng với một lần mua hàng Mối quan hệ này được minh họa trong hình 4-5.
Hình 4-5 Mối quan hệ kết hợp giữa hai lớp
4.3.1 Đặt tên cho các quan hệ kết hợp
Tên của quan hệ kết hợp thường là mệnh đề động từ đơn dễ hiểu, phản ánh mối liên hệ giữa các lớp trong ngữ cảnh của mô hình.
Tên của quan hệ kết hợp thường bắt đầu bằng động từ, hay tính động từ với chữ đầu được viết hoa
Giữa các từ trong tên của quan hệ được nối với nhau bằng ‘-‘
Ví dụ: Tên quan hệ giữa hai lớp PhienBanHang và ThanhToan là Được-trả- tiền-bởi như ở hình 4-5
Vấn đề quan trọng đặt ra là làm thế nào để xác định chính xác các mối quan hệ giữa các lớp trong hệ thống
4.3.2 Các phương pháp xác định các mối quan hệ kết hợp
Có hai phương pháp chính để xác định các mối quan hệ giữa các lớp trong hệ thống:
1 Mối quan hệ kết hợp giữa các lớp đối tượng là cần để 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 Dựa vào sự phân loại các phạm trù các quan hệ trong hệ thống
Xác định quan hệ kết hợp theo nguyên lý “ C ầ n để bi ế t ”
PhienBanHang 1 Được-trả-tiền-bởi 1 ThanhToan
Khi phân tích các yêu cầu, ta cần phải tuân theo các nguyên lý sau:
Quan hệ kết hợp hữu ích giúp chúng ta hiểu rõ về những mối quan hệ cần thiết để duy trì trong một khoảng thời gian nhất định, được gọi là sự kết hợp “cần để biết” (Need-to-know).
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", khi áp dụng vào 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 giữa nhu cầu, hành vi tiêu dùng và sự hiểu biết về sản phẩm Việc nắm rõ thông tin sản phẩm sẽ giúp người tiêu dùng đưa ra quyết định mua sắm thông minh hơn.
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 trạng thái thanh toán của hàng hóa đã bán, xác định xem khách hàng đã thanh toán đầy đủ hay chưa Hệ thống cũng quản lý số tiền khách đưa, tự động hoàn trả tiền thừa và hỗ trợ 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
Xác định mối quan hệ kết hợp dựa vào việc phân loại các phạm trù quan hệ
Việc xác định các quan hệ kết hợp tương tự như quá trình tìm kiếm các lớp, và chúng ta có thể dựa vào danh sách các phạm trù kết hợp để thực hiện điều này.
Trong việc phân tích hệ thống bán hàng HBH và hệ thống đặt vé máy bay, cần xem xét các phạm trù quan hệ để khám phá những mối liên kết tiềm năng giữa hai hệ thống này.
Các phạm trù kết hợp Các ví dụ
A là một bộ phận logic của B DongBanHang - PhienBanHang
A là một loại / lớp con / kiểu con của B ThanhToanTienMat – ThanhToan
A được chứa (vật lý) trong / trên B HBH - CuaHang
A được chứa (logic) trong B MoTaMatHang - DanhMucMatHang
A là một mô tả của B MoTaMatHang - MatHang
A là một mục trong một giao dịch DongBanHang – PhienBanHang
A là thành viên của B NguoiBan - CuaHang
A sử dụng hoặc quản lý B NguoiBan - HBH
A trao đổi với B KhachHang - NguoiBan
KhachBay – HangDatCho Giao dịch A có quan hệ với giao dịch B ThanhToan - PhienBanHang
A là sở hữu của B HBH - CuaHang
Dựa trên việc phân loại các phạm trù kết hợp và kinh nghiệm, kiến thức về hệ thống, cùng với kết quả khảo sát thực tế, chúng ta có thể liệt kê tất cả các mối quan hệ kết hợp thực tế giữa các lớp trong hệ thống Các lớp trong HBH thể hiện những quan hệ đa dạng và phức tạp, phản ánh sự tương tác và liên kết chặt chẽ giữa chúng.
Biểu đồ lớp
Biểu đồ lớp là công cụ quan trọng để mô tả cấu trúc tĩnh của hệ thống thông qua các lớp và mối quan hệ giữa chúng Nó giúp hiển thị các lớp và gói lớp, từ đó hỗ trợ người phát triển phần mềm trong việc quan sát và lập kế hoạch cấu trúc hệ thống trước khi bắt đầu lập trình Việc sử dụng biểu đồ lớp đảm bảo rằng hệ thống được thiết kế một cách hợp lý ngay từ đầu.
4.4.1 Các loại lớp trong biểu đồ
Biểu đồ lớp có thể bao gồm nhiều loại lớp khác nhau, như lớp thông thường, lớp tham số hóa, lớp hiện thực, lớp tiện ích và lớp metaclass (siêu lớp).
Lớp tham số hoá (Parameterized Class)
Lớp tham số hoá, hay còn gọi là lớp mẫu trong các ngôn ngữ lập trình mạnh như C++, cho phép tạo ra nhiều lớp khác nhau Trong UML, lớp tham số hoá được khai báo để tạo ra họ lớp Set với các phần tử có kiểu T tùy ý, được xem như là tham số.
Hình 4-6 Lớp được tham số hoá
Lớp tham số hoá là công cụ hữu ích để thể hiện quyết định thiết kế cho các giao thức trao đổi giữa các lớp, mặc dù ít được sử dụng trong mô hình khái niệm và chủ yếu trong mô hình cài đặt Việc sử dụng lớp tham số hoá phụ thuộc vào ngôn ngữ lập trình, ví dụ như C++ hỗ trợ cơ chế lớp mẫu, trong khi Java không hỗ trợ nhưng vẫn tạo ra cấu trúc cây phân cấp với lớp Object là gốc Nhờ vào tính chất phân cấp và nguyên lý bảo toàn mối quan hệ giữa các lớp con và lớp cha, chúng ta có thể xây dựng các cấu trúc tổng quát tương tự như lớp mẫu.
Lớp hiện thực (Instantiated Class)
Lớp hiện thực là loại lớp tham số hóa với đối số là kiểu trị cụ thể, trong đó lớp tham số hóa đóng vai trò như khuôn để tạo ra các lớp hiện thực Chẳng hạn, lớp Set chứa các số phức (Complex) là một ví dụ về lớp hiện thực, được biểu diễn trong UML như hình 4-7.
Hình 4-7 Lớp hiện thực hoá
Lớp tiện ích (Class Utility)
Lớp tiện ích là tập hợp các thao tác thường xuyên được sử dụng trong hệ thống, được tổ chức thành một lớp để các lớp khác có thể chia sẻ và sử dụng Trong biểu đồ, lớp tiện ích được biểu thị bằng lớp có đường viền bóng, như minh họa trong hình 4-8 (a).
Hình 4-8 (a) Lớp tiện ích (b) Giao diện
Giao diện là tập hợp các thao tác quan sát được từ bên ngoài của một lớp hoặc thành phần, không bao gồm nội dung cài đặt của lớp đó Giao diện thuộc về quan sát logic và có thể được thể hiện trong cả biểu đồ lớp và biểu đồ thành phần, với ký hiệu đồ họa tương ứng.
MetaClass là một lớp dùng để tạo ra các lớp khác, có nghĩa là chính nó là lớp chứ không phải là một đối tượng Lớp tham số hóa được xem như một loại siêu lớp trong lập trình.
Set insert(Complex e) remove(Complex e)
4.4.2 Mẫu rập khuôn (stereotype) của các lớp
Mẫu rập khuôn (Stereotype) là cơ chế mở rộng mô hình, cho phép tạo ra các phần tử mới và dễ dàng bổ sung thông tin cho chúng Nó giúp phân loại các lớp đối tượng trong các dự án và quá trình phát triển phần mềm.
Rational Rose đã xây dựng một số stereotype như , ,
, , v.v., ngoài ra chúng ta có thể định nghĩa những loại kiểu mới cho mô hình hệ thống
Lớp biên là lớp nằm trên đường biên của hệ thống với phần thế giới bên ngoài
Lớp biên trong UML có thể đại diện cho các biểu mẫu, báo cáo, hoặc giao diện với thiết bị phần cứng như máy in và máy quét Để xác định lớp biên, cần khảo sát biểu đồ ca sử dụng, trong đó một tác nhân có thể tương ứng với một lớp biên Nếu có hai tác nhân cùng kích hoạt một ca sử dụng, chỉ cần tạo một lớp biên chung cho cả hai.
Lớp thực thể (Control Class)
Lớp thực thể là lớp lưu giữ các thông tin mà nó được ghi vào bộ nhớ ngoài Ví dụ lớp
SinhVien là lớp thực thể Trong UML, lớp thực thể được ký hiệu như trong hình 4-9 (b)
Lớp thực thể xuất hiện trong các luồng sự kiện và biểu đồ tương tác, thường yêu cầu tạo bảng dữ liệu trong cơ sở dữ liệu (CSDL) cho mỗi lớp Mỗi thuộc tính của lớp thực thể sẽ trở thành một trường dữ liệu trong bảng tương ứng.
Lớp điều khiển đóng vai trò quan trọng trong việc điều phối hoạt động của các lớp khác trong hệ thống Mỗi ca sử dụng thường có một lớp điều khiển riêng để quản lý trình tự các sự kiện Mặc dù lớp điều khiển không thực hiện các chức năng nghiệp vụ trực tiếp, nhưng nó gửi nhiều thông điệp đến các lớp liên quan, do đó còn được gọi là lớp quản lý Trong biểu đồ UML, lớp điều khiển được ký hiệu theo hình 4-9 (c).
Hình 4-9 (a) Lớp biên (b) Lớp thực thể (c) Lớp điều khiển
4.4.3 Biểu đồ lớp trong Hệ HBH
Trong số những quan hệ kết hợp đã phát hiện ở mục 4.3, dễ nhận thấy lớp
DanhMucMatHang chứa các MoTaMatHang, do vậy giữa hai lớp này có quan hệ kết nhập
Trong mỗi Phiên Bán Hàng, tồn tại nhiều Dòng Bán Hàng, tạo nên mối quan hệ kết nhập giữa hai lớp này Bằng cách kết hợp tất cả các mối quan hệ giữa các lớp đã phân tích trước đó, chúng ta có thể xây dựng biểu đồ lớp một cách rõ ràng và logic.
Hình 4-10 Biểu đồ lớp của HBH
Thuộc tính của lớp
Thuộc tính của lớp mô tả các đặc điểm của các đối tượng trong lớp đó, chẳng hạn như lớp KhachHang có các thuộc tính như họ tên, địa chỉ và số tài khoản Tại mỗi thời điểm, thuộc tính của một đối tượng trong lớp thể hiện giá trị dữ liệu logic, phản ánh tính chất tương ứng của đối tượng, được gọi là giá trị thuộc tính của đối tượng tại thời điểm đó.
+ Kiểu xác định các loại giá trị mà thuộc tính mô tả,
+ Giá trị mặc định (khởi đầu) cho mỗi thuộc tính Việc gán giá trị khởi đầu cho thuộc tính là tuỳ chọn, không bắt buộc
NguoiQL Được-trả Được-quản-lý-bởi
CuaHang Được-mô-tả-bởi Ghi-nhận-hàng-bán
1 Được-khởi-động-bởi Được-thực-hiện-bởi
Kiểu của thuộc tính là kiểu dữ liệu cơ sở hoặc các lớp đã được xây dựng trước, cho biết về loại giá trị như số nguyên (Integer, int) và số thực (Real).
Các kiểu nguyên thuỷ trong lập trình bao gồm số thực (Float), giá trị logic (Boolean), ký tự (Character), và thời gian (Time) Bên cạnh các kiểu nguyên thuỷ này, lập trình viên có khả năng tạo ra các kiểu dữ liệu mới theo nhu cầu của hệ thống.
Phạm vi của thuộc tính
Lớp có thêm đặc tính thể hiện khả năng nhìn thấy và quản lý quyền truy cập của thuộc tính đối với các đối tượng khác, được gọi là phạm vi quan sát Phạm vi này áp dụng cho thuộc tính và các thành phần trong lớp, và được khai báo bằng các ký hiệu trong lớp.
Trong UML, thuộc tính công khai được biểu thị bằng dấu ‘+’ hoặc biểu tượng ổ khóa trong Rose, cho phép mọi đối tượng trong hệ thống nhìn thấy và truy cập thuộc tính này từ bất kỳ lớp nào khác.
Trong UML, thuộc tính được đánh dấu bằng ký hiệu ‘#’ hoặc biểu tượng ổ khóa với chìa khóa bên cạnh trong Rose, cho thấy thuộc tính này là được bảo vệ (protected) Chỉ những đối tượng có quan hệ kế thừa mới có khả năng truy cập và nhìn thấy thuộc tính này.
Trong UML, dấu '-' đứng trước thuộc tính hoặc biểu tượng khóa bị khóa trong Rose biểu thị rằng thuộc tính đó là riêng tư (private), chỉ có đối tượng của lớp đó mới có thể nhìn thấy, trong khi các đối tượng khác không được phép truy cập.
Trong lập trình, thuộc tính không có ký hiệu phạm vi nào được xem là mặc định, với biểu tượng mặc định trong Rose là "mặc định" Điều này có nghĩa là các thuộc tính này có thể được quan sát đối với các lớp trong cùng một gói Phạm vi mặc định còn được gọi là phạm vi gói hoặc phạm vi cài đặt.
KhachHang hoTen : String diaChi : String taiKhoan : Integer tuoi : Integer
Hình 4-11 Các thuộc tính của lớp trong UML và trong Rose
Thuộc tính hoTen có kiểu String và là công khai, soTaiKhoan có kiểu int (các số nguyên) là riêng còn diaChi là được bảo vệ, có kiểu String
Khi cài đặt chương trình, phạm vi quan sát của thuộc tính phụ thuộc vào các quy định khác nhau của ngôn ngữ lập trình được chọn Chẳng hạn, tính chất mặc định và tính chất được bảo vệ của thuộc tính trong C++ và Java có sự khác biệt rõ rệt.
Tính chất lưu trữ thuộc tính
Các thuộc tính trong lớp nếu được xác định thì có thể lưu trữ theo giá trị, hoặc theo tham chiếu, ngược lại chưa xác định
Giá trị (By value): thuộc tính được gán tính chất By value trong mô hình thì nó sẽ được lưu trong lớp bền vững chứa thuộc tính đó
Tham chiếu (Reference): thuộc tính được gán giá trị này cho biết nó sẽ được lưu trữ ở bên ngoài lớp, nhưng có con trỏ tham chiếu đến nó
Chưa xác định (Unspecified) là thuộc tính cho biết cách lưu trữ chưa được xác định Tuy nhiên, khi mã chương trình được phát sinh, Rose sẽ coi thuộc tính này là By value.
Mỗi thuộc tính trong một lớp thường có bản sao dữ liệu riêng cho từng đối tượng, như lớp NguoiBanHang với các thuộc tính tenGoi và taiKhoan Khi tạo ra hai đối tượng người bán hàng, mỗi người sẽ có một bản sao riêng của tenGoi và taiKhoan, dẫn đến việc mỗi người sử dụng một tài khoản khác nhau Tuy nhiên, thực tế cho thấy tất cả người bán hàng nên chia sẻ một tài khoản chung, đó là tài khoản của Công ty Để khắc phục vấn đề này, có thể sử dụng thuộc tính static cho taiKhoan, giúp tất cả người bán hàng truy cập vào cùng một tài khoản.
Các thuộc tính khai báo static trong một lớp được chia sẻ giữa tất cả các đối tượng, nghĩa là chỉ có một bản sao dữ liệu cho tất cả các đối tượng của lớp đó.
UML biểu diễn thuộc tính static bằng dấu ‘$’ trước tên thuộc tính
Thuộc tính suy dẫn (derived)
Một số thuộc tính có thể được suy dẫn từ những thuộc tính khác Ví dụ, lớp
HinhChuNhat có thuộc tính chieuCao, chieuRong, nếu có thêm thuộc tính dienTich thì tất nhiên dienTich là có thể suy ra từ tích của chieuCao * chieuRong
Trong UML, thuộc tính suy dẫn được ký hiệu bằng dấu ‘/’ trước tên thuộc tính Đặc tính lưu trữ đối tượng
Trong các hệ thống đối tượng, đối tượng cần lưu trữ trong cơ sở dữ liệu được gọi là đối tượng duy trì, trong khi đối tượng không cần lưu trữ bên ngoài được gọi là đối tượng không bền vững Trong phần mềm Rose, có thể gán đặc tính lưu trữ cho lớp, với các đặc tính này có thể được xác định rõ ràng.
Persistent: là những lớp chứa các đối tượng được lưu trữ trong cơ sở dữ liệu hoặc trong một khuôn mẫu nào đó, có nghĩa là chúng vẫn tồn tại ngay cả khi hệ thống không hoạt động.
Transient: cho những lớp mà các đối tượng của nó không cần lưu trữ vào bộ nhớ ngoài
Lớp trừu tượng là những lớp không có đối tượng cụ thể trong thực tế, thường được sử dụng làm nền tảng cho các lớp khác kế thừa.
4.5.1 Tìm kiếm các thuộc tính
Các phương thức của lớp
Phương thức của lớp là các hàm mô tả hành vi và mối quan hệ của đối tượng trong hệ thống, bao gồm phạm vi, tên gọi, danh sách tham số và kiểu giá trị trả về Cú pháp của phương thức được định nghĩa như sau: visibility name (arg1: DataType1, arg2: DataType2, …, argn: DataTypen): ReturnType Trong đó, visibility xác định phạm vi quan sát của phương thức, có thể là public, protected, private, hoặc mặc định Tên gọi của phương thức thường là động từ, với quy tắc viết hoa chữ cái đầu tiên của các từ, ngoại trừ từ đầu tiên Các tham số được chỉ định bằng tên và kiểu dữ liệu tương ứng.
DataTypek là các kiểu thuộc tính, thường đó là các kiểu của các thuộc tính đã khai báo trong lớp
ReturnType là kiểu dữ liệu trả lại sau khi phương thức kết thúc Những phương thức không có kiểu trả lại (các thủ tục) thì sử dụng Void (void)
Ví dụ: trong lớp ThanhToan có phương thức
+ makePayment(upc: UPC, n: Integer): Boolean
Trong thiết kế lớp, các phương thức thường được trình bày ngắn gọn với tên và danh sách tham số để đơn giản hóa Ví dụ, phương thức có thể được viết tắt là + makePayment(upc, n), trong đó upc đại diện cho mã sản phẩm và n là số lượng mặt hàng mà khách hàng muốn mua.
Khi thiết kế các lớp, một câu hỏi thường gặp là có những loại phương thức nào Thực tế, có năm loại phương thức chính: nghiệp vụ, quản lý, truy cập, hiển thị (trao đổi) và trợ giúp.
Phương thức nghiệp vụ (thực thi) là một chức năng quan trọng mà lớp đối tượng cần thực hiện Những phương thức này được xác định từ các thông điệp gửi đến lớp đối tượng trong các biểu đồ tương tác Chẳng hạn, khi lớp ThanhToan nhận thông điệp makePayment(soTien) trong biểu đồ cộng tác hoặc biểu đồ trình tự, lớp này sẽ có phương thức makePayment(soTien) để thực hiện chức năng thanh toán.
Phương thức quản lý là cách thức xử lý các đối tượng trong lớp, bao gồm việc tạo lập và huỷ bỏ các đối tượng Các toán tử tạo lập và huỷ tử thuộc nhóm này, đóng vai trò quan trọng trong việc quản lý vòng đời của đối tượng.
Phương thức truy cập trong lập trình là cách mà các thuộc tính private và protected trong lớp được quản lý để hạn chế quyền truy cập từ các đối tượng khác Tuy nhiên, để các đối tượng trong các lớp khác có thể tương tác và truy cập dữ liệu cần thiết, việc sử dụng các phương thức truy cập để đọc và ghi dữ liệu thành phần là rất quan trọng.
Trong lớp KhachHang, thuộc tính taiKhoan được khai báo là private để bảo vệ thông tin khỏi truy cập trái phép Tuy nhiên, để thực hiện thanh toán, hệ thống cần có phương thức truy cập vào taiKhoan của khách hàng, vì vậy các phương thức như getTaiKhoan() để đọc và setTaiKhoan() để cập nhật số tiền là cần thiết.
Những phương thức loại này thường khai báo là public
Phương thức trợ giúp là những phương thức mà các lớp chứa nó cần thực hiện các nhiệm vụ được giao Những phương thức này thường có tính chất private hoặc protected, đảm bảo tính bảo mật và kiểm soát trong quá trình thực thi.
Phương thức hiển thị và trao đổi thông tin là các phương pháp đảm nhận việc hiển thị dữ liệu trên các thiết bị ngoại vi như máy in, máy vẽ và màn hình, cũng như chuyển giao thông tin qua các kênh truyền thông trực tuyến.
Ghi nhận trong từ điển thuật ngữ
Từ điển thuật ngữ là tài liệu quan trọng trong phát triển phần mềm, giúp định nghĩa rõ ràng các thuật ngữ và hạng mục Nó không chỉ hỗ trợ giao tiếp hiệu quả giữa các thành viên trong dự án mà còn giảm thiểu rủi ro do hiểu lầm Dưới đây là một ví dụ về từ điển thuật ngữ trong hệ HBH.
Hạng mục Phạm trù Chú thich
Bán hàng Ca sử dụng Mô tả quá trình bán hàng cho khách trong một cửa hàng
MoTaMatHang.moTa: Text Thuộc tính Mô tả ngắn gọn về mặt hàng ở trong lớp MoTaMatHang
MatHang Lớp (kiểu) Hàng để bán trong một cửa hàng
ThanhToan Lớp (kiểu) Lớp làm nhiệm vụ thu tiền mà khách hàng trả khi mua hàng MoTaMatHang.giaBan: Number Thuộc tính Giá bán của mặt hàng ở trong
MoTaMatHang DongBanHang.soLuong: Int Thuộc tính Số lượng một mặt hàng mà khách mua PhienBanHang Lớp (kiểu) Một giao dịch bán hàng
DongBanHang Lớp (kiểu) Một dòng trong phiên giao dịch bán hàng CuaHang Lớp (kiểu) Nơi có các giao dịch bán hàng
Tổng số tiền khách hàng phải thanh toán trong một lần mua hàng được xác định bởi thuộc tính PhienBanHang.tongSoTien Trong khi đó, thuộc tính ThanhToan.tongSo thể hiện tổng số tiền cần thu từ khách hàng Mã sản phẩm được ghi nhận trong MoTaMatHang thông qua thuộc tính MoTaMatHang.maSanPham, giúp dễ dàng quản lý và theo dõi sản phẩm.
Từ điển thuật ngữ thường được xây dựng qua nhiều giai đoạn, bắt đầu từ việc định nghĩa bài toán và khảo sát các ca sử dụng Sau đó, các hạng mục sẽ được tạo ra và tiếp tục được bổ sung, làm mịn hơn trong các pha tiếp theo Quá trình xây dựng từ điển thuật ngữ diễn ra song song với các công việc như đặc tả yêu cầu, xây dựng ca sử dụng, thiết lập mô hình khái niệm và biểu đồ tuần tự, cũng như các hoạt động cộng tác khác.
Không có mẫu chính thức nào có thể áp dụng cho việc mô tả từ điển thuật ngữ.
Thực hành trong Rational Rose
Sử dụng Rational Rose ([11], [17]) để thực hiện những công việc sau:
1 Tạo lập và huỷ bỏ biểu đồ lớp Lưu ý: trong Rose, biểu đồ lớp được thiết lập trong quan sát logic (Logical View), khi tạo lập mô hình mới biểu đồ lớp
Trong Logical View, chúng ta có thể tạo ra nhiều biểu đồ khác nhau để mô tả mô hình cấu trúc tĩnh của hệ thống.
2 Bổ sung thêm các loại lớp: lớp thông thường, lớp hiện thực, lớp tiện ích, v.v
3 Đặc tả các lớp: tên lớp, chọn stereotype, đặc tính xác định phạm lớp (Public,
Protected, Private, Package hay Implementation), đặc tính lưu trữ của lớp (Persistent, Transient), v.v
4 Tạo lập và huỷ bỏ gói (Package),
5 Đưa các thuộc tính vào lớp: tên, kiểu và gán trị khởi đầu, gán các thuộc tính lưu trữ (By Value, By Reference, Unspecified), gán thuộc tính tĩnh (Static), gán thuộc tính suy dẫn (Derived),
6 Thiết lập các mối quan hệ giữa các lớp trong biểu đồ: tên gọi và hướng của quan hệ, gán stereotype, các vai trò Role cho quan hệ, phạm vi của quan hệ (Public, Protected,
Private, Package hay Implementation) và các thuộc tính khác như Static, By Value, By Reference, Unspecified, Friend, Link Element, Key / Qualifier, v.v
Thực hành các chức năng trên để xây dựng biểu đồ lớp ở hình 4-10 và sau đó bổ sung thêm các thuộc tính từ hình 4-14
Rational Rose 4.0 hỗ trợ phiên bản demo cho ngôn ngữ lập trình C++ trên hệ điều hành Windows 95, có thể tải về từ http://www.rational.com/demos Đây là công cụ hữu ích cho việc phân tích và thiết kế hệ thống hướng đối tượng Tuy nhiên, một số ký pháp của UML vẫn chưa được tích hợp trong Rose.
Rose không cho phép vẽ hình chữ nhật giới hạn đường biên của hệ thống
Biểu đồ lớp trong Rose thiếu ký hiệu biểu diễn cho các loại quan hệ kết nhập khác nhau (kết nhập thông thường, chia sẻ và hợp thành)
Trong biểu đồ trình tự không có ký hiệu cho sự kiện tạo lập và huỷ bỏ đối tượng
Câu hỏi và bài tập
4.1 Điền vào chỗ chống của những câu sau:
+ Sự khác biệt chính giữa phân tích hướng đối tượng và phân tích có cấu trúc là sự phân rã hệ thống thành
+ Trong UML mô hình khái niệm của một hệ thống được mô tả bởi
trong các mô tả văn bản đó có thể là đại biểu của lớp hoặc thuộc tính của lớp
Dựa vào sự phân loại các phạm trù khái niệm, chúng ta có thể xây dựng một hệ thống hiệu quả Quan hệ kết hợp giữa hai lớp đóng vai trò quan trọng trong việc xác định các đối tượng thuộc hai lớp đó.
+ Các đối tượng có mối quan hệ với nhau mới có thể cộng tác với nhau theo các đường giữa các lớp
+ Lớp trừu tượng là còn lớp cụ thể là
+ Trong hệ thống hướng đối tượng, các đối tượng được xác định duy nhất
4.2 Nêu một số phương pháp chính để phát hiện các lớp đối tượng trong giai đoạn phân tích hệ thống theo cách tiếp cận hướng đối tượng
4.3 Mô tả trong UML để thể hiện: “Mỗi sinh viên có thể theo học nhiều nhất là 6, ít nhất là
4 môn học và mỗi môn học có nhiều nhất là 30 sinh viên có thể ghi danh
4.4 Xác định các lớp và thiết lập biểu đồ lớp cho hệ thống “Quản lý thư viện” (Tiếp theo của bài tập 3.4)
4.5 Xây dựng mô hình khái niệm cho “Hệ thống rút tiền tự động ATM (Automatic Teller Machine)” (Tiếp theo của bài toán 3.5)
4.6 Xây dựng mô hình khái niệm cho hệ thống “Mô phỏng hệ thống thang máy cho các nhà cao tầng” (Tiếp theo của bài toán 3.6)
4.7 Áp dụng phương pháp phân tích các mục đích của các ca sử dụng để chuyển biểu đồ ca sử dụng ở hình sau sang biểu đồ lớp
Hệ thống bán sách Đặt mua sách
4.8 Chọn từ danh sách dưới đây những thuật ngữ thích hợp để điền vào các chỗ [(…)] trong đoạn văn mô tả về mục tiêu của phương pháp hướng đối tượng
Mục tiêu chính của việc phân tách hệ thống là xác định các đối tượng, những thành phần mà chúng ta đã hiểu rõ Mô hình này là phương pháp biểu diễn các yếu tố trong bối cảnh của bài toán.
Chọn câu trả lời: a khái niệm b thực thể c phương pháp hướng đối tượng d sự vật
MÔ HÌNH ĐỘNG THÁI: CÁC BIỂU ĐỒ TƯƠNG TÁC VÀ HÀNH ĐỘNG TRONG HỆ THỐNG
Mô hình hoá hành vi hệ thống
Tất cả các hệ thống đều bao gồm cấu trúc tĩnh và hành vi động cần được mô hình hóa UML cung cấp các biểu đồ giúp thể hiện cả hai khía cạnh này một cách rõ ràng và hiệu quả.
Cấu trúc tĩnh được mô tả bởi: biểu đồ lớp, các đối tượng và các mối quan hệ của chúng
Hành vi động được mô tả bởi: biểu đồ trạng thái, trình tự, cộng tác và biểu đồ hành động
Các đối tượng trong hệ thống tương tác với nhau thông qua việc gửi các thông điệp để thực hiện nhiệm vụ Sự tương tác này được minh họa thông qua các biểu đồ, thể hiện rõ cách thức trao đổi thông tin giữa các đối tượng.
Biểu đồ trạng thái (StateDiagram) là công cụ mô tả các trạng thái và hành vi của đối tượng Nó cung cấp thông tin về các trạng thái khác nhau mà đối tượng có thể trải qua, đồng thời thể hiện cách thức chuyển đổi giữa các trạng thái Biểu đồ cũng nêu rõ hành vi của từng đối tượng khi có các sự kiện xảy ra, dẫn đến sự thay đổi trạng thái.
Biểu đồ trình tự (Sequence Diagram) mô tả sự tương tác và trao đổi giữa các đối tượng theo thứ tự thời gian Nó bao gồm các phần tử đại diện cho các đối tượng cùng với các thông điệp được gửi và nhận, giúp thể hiện trình tự thực hiện các ca sử dụng trong hệ thống.
(iii) Biểu đồ cộng tác (Collaboration Diagram): mô tả sự tương tác của các đối tượng với nhau theo ngữ cảnh và không gian công việc
Biểu đồ hành động (Activity Diagram) là một công cụ mạnh mẽ giúp mô tả sự tương tác giữa các đối tượng, đồng thời nhấn mạnh vào các công việc cụ thể Nó xác định rõ ràng các hành động cần thực hiện và thứ tự thực hiện những hành động đó, từ đó hỗ trợ việc phân tích và thiết kế quy trình làm việc hiệu quả.
Xây dựng biểu đồ tương tác là thực hiện việc gán trách nhiệm cho các đối tượng
Biểu đồ tương tác giúp người thiết kế nhận diện các lớp và các thao tác cần thực hiện cho mỗi lớp Vì vậy, nó đóng vai trò quan trọng trong việc làm nền tảng cho các bước tiếp theo trong quá trình phát triển phần mềm.
Không phải tất cả các hệ thống đều cần bốn biểu đồ để mô tả hành vi của các đối tượng trong ca sử dụng Số lượng biểu đồ tương tác cần xây dựng phụ thuộc vào độ khó và phức tạp của bài toán ứng dụng Một số người sử dụng biểu đồ trình tự và biểu đồ trạng thái trong pha phân tích để mô tả hoạt động của hệ thống, sau đó phát triển biểu đồ cộng tác và biểu đồ hành động cho thiết kế chi tiết Đối với các hệ thống đơn giản, chỉ cần sử dụng biểu đồ trình tự và biểu đồ trạng thái.
5.1.1 Các sự kiện và hành động của hệ thống
Trong quá trình tương tác với hệ thống, các tác nhân tạo ra sự kiện yêu cầu hệ thống thực hiện các thao tác cần thiết Những sự kiện này có mối liên hệ chặt chẽ với các hoạt động mà hệ thống cần thực hiện Do đó, việc xác định các hoạt động của hệ thống thông qua các sự kiện do tác nhân gây ra là điều quan trọng.
Sự kiện là hành động kích hoạt hệ thống, khiến nó hoạt động hoặc tiếp tục hoạt động theo một cách nhất định Đơn giản hơn, sự kiện là điều gì đó xảy ra và có thể dẫn đến các hoạt động tiếp theo của hệ thống Chẳng hạn, khi người bán nhấn phím “Kết thúc” sau khi nhập tất cả mặt hàng mà khách đã chọn, hệ thống sẽ chuyển sang thực hiện chức năng thanh toán cho khách hàng Hành động nhấn phím “Kết thúc” chính là sự kiện làm thay đổi trạng thái của hệ thống.
Các sự kiện có thể chia thành hai loại: độc lập và phụ thuộc Ví dụ, việc nhập thông tin về các mặt hàng và thanh toán là hai sự kiện phụ thuộc, trong đó thanh toán phải diễn ra sau khi đã nhập thông tin Ngược lại, sự kiện trả tiền mặt và trả bằng séc là hai sự kiện độc lập, không có sự ràng buộc về thời gian giữa chúng.
Những sự kiện độc lập có thể xảy ra đồng thời mà không phụ thuộc vào nhau Chẳng hạn, việc hiển thị số tiền dư trả lại cho khách và cập nhật các mặt hàng trong hệ thống HBH là hai sự kiện độc lập, cho phép thực hiện cùng một lúc.
Các sự kiện cũng có thể chia thành hai loại: các sự kiện bên trong và các sự kiện bên ngoài
Sự kiện bên trong là sự kiện xảy ra ngay bên trong hệ thống, ở trong một đối tượng và được kích hoạt bởi đối tượng khác
Sự kiện ngoài là những sự kiện phát sinh bên ngoài hệ thống, trong khi sự kiện vào là các sự kiện ngoài tác động đến hệ thống, được tạo ra bởi các tác nhân khác.
Hoạt động của hệ thống bao gồm các thao tác cần thiết để phản hồi các sự kiện đầu vào Những hoạt động này không chỉ tạo ra các sự kiện đầu ra cho các tác nhân mà còn thông báo về các sự kiện tiếp theo có thể xảy ra, đồng thời hướng dẫn các tác nhân về cách hành động để đạt được thông tin mong muốn Rõ ràng, các sự kiện đầu vào là yếu tố kích hoạt hệ thống, và hệ thống hoạt động nhằm đáp ứng các sự kiện đầu vào do các tác nhân tạo ra.
Các sự kiện và hoạt động trong hệ thống thường được sử dụng để mô tả kịch bản cho ca sử dụng Ví dụ, trong kịch bản ca sử dụng "Gọi điện thoại", có hai tác nhân là người gọi và người nghe Dãy sự kiện của ca sử dụng này được mô tả chi tiết.
Các sự kiện vào Các sự kiện ra
1 Người gọi nhấc tai nghe 2 Tiếng bíp bíp báo hiệu máy điện thoại sẵn sàng để bắt đầu trao đổi đàm thoại
3 Người gọi quay số (ví dụ 5652 288) 4 Tín hiệu điện thoại được nối với người nghe
5 Điện thoại của người được gọi rung chuông (nếu không bận đàm thoại)
6 Người nghe nhấc ống tai nghe và trả lời 7 Chuông ngừng kêu
8 Đường dây điện thoại được kết nối để hai người đàm thoại với nhau
9 Người nghe đặt tai nghe xuống 10 Đường dây bị ngắt
11 Người gọi đặt tai nghe xuống kết thúc cuộc gọi
Các sự kiện vào là do người gọi tạo ra, các sự kiện ra lại tác động đến người nghe
Hệ thống điện thoại hoạt động để phản hồi các sự kiện và đồng thời tạo ra những sự kiện mới Các sự kiện và hoạt động của hệ thống được mô tả một cách trực quan, bắt đầu với âm hiệu sẵn sàng.
Người nghe trả lời Đường dây thông
Người nghe Nhấc tai nghe Âm hiệu mời gọi Quay số ĐT để gọi
Chuông ngừng kêu Đường dây thông
Hình 5-1 Biểu đồ vết các sự kiện khi thực hiện ca sử dụng “Gọi điện thoại”
5.1.2 Sự trao đổi thông điệp giữa các đối tượng
Trong các biểu đồ tương tác, các đối tượng trao đổi với nhau bằng các thông điệp Các đối tượng thường được gửi, nhận theo:
Các giao thức trao đổi tin (Communication Protocol),
Hay các lời gọi hàm, một đối tượng gọi một hàm của đối tượng khác để xử lý các yêu cầu
Có thể thực hịên việc trao đổi thông tin trên mạng, hoặc trong một máy tính và phần lớn thực hiện trong thời gian thực (Real-Time)
Các thông điệp có ba kiểu trao đổi chính:
1 Kiểu đơn giản: được ký hiệu là
Biểu đồ trình tự
Trong giai đoạn phân tích, hệ thống được định nghĩa như một hộp đen, chỉ thể hiện hành vi cần thực hiện mà không cần biết cách thực hiện Nhiệm vụ chính của chúng ta là xác định và mô tả các hoạt động của hệ thống theo yêu cầu của các tác nhân, tìm ra các sự kiện và thao tác trong từng ca sử dụng Biểu đồ trình tự sẽ giúp thể hiện những kết quả này một cách rõ ràng.
5.2.1 Các thành phần của biểu đồ trình tự
Biểu đồ trình tự mô tả quá trình trao đổi thông điệp giữa các đối tượng theo thời gian, với thông điệp được gửi và nhận bởi các đối tượng hoạt động trong hệ thống Biểu đồ này được thể hiện trên hai trục, giúp người xem dễ dàng theo dõi sự tương tác và luồng thông tin giữa các thành phần.
Trục dọc của biểu đồ biểu thị thời gian diễn ra các sự kiện hoặc quá trình truyền thông điệp, được thể hiện qua các đường thẳng đứng đứt nét kéo dài từ đỉnh đến đáy.
Trục ngang từ trái qua phải biểu thị các đối tượng tham gia vào việc trao đổi thông điệp, bao gồm cả các tác nhân Mỗi đối tượng được thể hiện bằng hình chữ nhật, trong đó có tên đối tượng cụ thể và/hoặc tên lớp được gạch dưới, với tên lớp cũng có thể đại diện cho bất kỳ đối tượng nào thuộc lớp đó.
Biểu đồ trình tự được đọc từ trên xuống dưới và từ trái sang phải, với các đối tượng được sắp xếp đơn giản để dễ quan sát Thời gian thực hiện một thông điệp của đối tượng, hay còn gọi là hoạt động của đối tượng, được biểu diễn bằng hình chữ nhật hẹp dọc theo trục thẳng đứng của đối tượng đó.
Ví dụ, :MyComputer gửi một thông điệp print(aFile) tới :Printer được mô tả như hình 5-2
Hình 5-2 Các thành phần cơ bản của biểu đồ trình tự
Mỗi thông điệp đều mang một tên gọi thể hiện ý nghĩa của thông tin cần truyền tải cùng với các tham số dữ liệu liên quan, thường là các lời gọi hàm Khi định nghĩa các lớp, mỗi thông điệp nhận được sẽ trở thành một phương thức Đặc biệt, một đối tượng có thể gửi thông điệp tới chính nó, được gọi là phản thân, cho thấy rằng đối tượng thực hiện các thao tác của chính mình.
Chú ý rằng tác nhân ngoài kích hoạt các đối tượng trong biểu đồ trình tự hoạt động, nhưng nó không phải là phần tử của biểu đồ loại này
Notes được sử dụng để chú thích cho các đối tượng trong biểu đồ trình tự, trong khi Scripts chú thích cho các thông điệp Scripts được đặt bên trái hoạt động của đối tượng, tương ứng với mức thông điệp cần chú thích Chúng giúp mô tả các điều kiện logic hoặc điều kiện lặp, chẳng hạn như lệnh.
IF hay WHILE, v.v trong quá trình trao đổi thông điệp Scripts không hỗ trợ để tạo ra
:MyComputer :Printer print(aFile) mã chương trình, nhưng nó giúp cho người phát triển hệ thống biết được những điều kiện cần phải tuân theo
Hình 5-3 Scripts trong biểu đồ trình tự
Trong trường hợp sử dụng "Gọi điện thoại", có hai tác nhân chính là Caller (người gọi) và Callee (người nghe) Hệ thống ghi nhận các sự kiện thông qua các lời gọi hàm như: liftReceiver() (nhấc tai nghe), dialsPhoneNumber() (quay số), answerPhone() (trả lời điện thoại) và hangUp() (đặt tai nghe xuống, nhấc tay lên) Biểu đồ trình tự mô tả các hoạt động này được xác định rõ ràng.
Hình 5-4 Biểu đồ trình tự mô tả hoạt động “Gọi điện thoại”
5.2.2 Xây dựng biểu đồ trình tự
Các bước xây dựng biểu đồ trình tự
1 Xác định các tác nhân, các đối tượng tham gia vào ca sử dụng và vẽ chúng theo hàng ngang trên cùng theo đúng các ký hiệu,
2 Xác định những thông điệp (lời gọi hàm) mà tác nhân cần trao đổi với một đối tượng nào đó, hoặc giữa các đối tượng tương tác với nhau theo trình tự thời gian và vẽ lần lượt các hoạt động đó từ trên xuống theo thứ tự thực hiện trong thực tế Cần xác định chính xác các loại thông điệp trao đổi giữa các đối tượng là đơn giản, đồng bộ hay dị bộ
: System liftReceiver() dialsPhoneNumber() answerPhone() hangUp() hangUp()
5.2.3 Các biểu đồ trình tự mô hình hành động của hệ HBH
Chúng ta đang phát triển các biểu đồ trình tự để mô tả hành vi của hệ thống bán hàng HBH Hành vi này được thể hiện qua sự tương tác giữa các đối tượng, với các lời gọi hàm được khai báo công khai trong các lớp.
Biểu đồ mô tả hoạt động của người bán hàng và hệ thống
Sau khi chọn đủ hàng, người mua sẽ đưa giỏ hàng đến quầy để thanh toán Người bán cần nhập thông tin và số lượng của từng mặt hàng, thường được xác định qua mã sản phẩm UPC Để thực hiện điều này, người bán gửi thông điệp enterItems()(upc, n) đến hệ thống bán hàng, bao gồm mã sản phẩm và số lượng cần mua Khi hoàn tất việc nhập hàng, người bán nhấn nút Kết thúc để gửi thông điệp endSale() cho hệ thống, từ đó hệ thống sẽ thông báo tổng số tiền phải trả Nếu khách hàng thanh toán bằng tiền mặt, người bán tiếp tục gửi thông điệp makePayment(soTien) đến hệ thống.
Các hoạt động trên được mô tả trong biểu đồ trình tự như hình 5-5
Hình 5-5 Biểu đồ trình tự mô tả sự tương tác giữa người bán và hệ thống
Biểu đồ trình tự mô tả ca sử dụng “Thanh toán tiền mặt”
Khi hệ thống nhận yêu cầu thanh toán từ khách hàng qua người bán, nó sẽ gửi yêu cầu tương tự đến đối tượng phiên bán hàng Đối tượng này sẽ tạo ra một đối tượng thanh toán để xử lý số tiền khách hàng đưa Sau khi thực hiện thanh toán, đối tượng thanh toán sẽ gửi thông điệp về số dư còn lại cho hệ thống, giúp hiển thị số tiền cần trả lại cho khách hàng Thông tin này sẽ được người bán thông báo lại cho khách khi họ thanh toán bằng tiền mặt.
:HeThong enterItems(upc, n) endSale()() makePayment(soTien):NguoiBan đồ trình tự mô tả dãy các hành động trao đổi giữa các đối tượng nêu trên được thiết lập như sau:
Hình 5-6 Biểu đồ trình tự mô tả ca sử dụng “Thanh toán (tiền mặt)”
Biểu đồ trình tự mô tả ca sử dụng “Thanh toán bằng thẻ tín dụng”
Khách hàng có thể thanh toán bằng thẻ tín dụng thông qua việc gửi thông điệp makeCreditPayment(soHieuThe, hanSD) cho hệ thống Hệ thống sẽ gửi yêu cầu kiểm duyệt thẻ requestApproval(yeuCau) tới bộ phận kiểm duyệt thẻ tín dụng Dựa vào kết quả từ bộ phận này, hệ thống sẽ xử lý thanh toán bằng cách trừ số tiền mua hàng từ thẻ tín dụng nếu thẻ hợp pháp, thông qua hàm handleCreditReply() Biểu đồ trình tự thể hiện sự tương tác giữa người bán, hệ thống và bộ phận kiểm duyệt thẻ KiemDuyet.
Hình 5-7 Biểu đồ trình tự mô tả sự trao đổi giữa người bán, hệ thống và bộ phận kiểm duyệt
: PhienBanHang : ThanhToan makePayment(soTien) makePayment(soTien) makePayment(soTien) balance() balance() displayBalance ()
KiemDuyet makeCreditPayment(soHieuThe, hanSD) handleCreditReply() requestApproval(yeuCau)
Tương tự như trên, chúng ta có thể tạo ra những biểu đồ trình tự cho các ca sử dụng khác của hệ thống
5.2.4 Ghi nhận các hoạt động của các lớp đối tượng Ở chương 4 chúng ta đã xây dựng các lớp và tập trung chủ yếu vào việc phát hiện các thuộc tính của chúng Khi đã xây dựng được các biểu đồ trạng thái và biểu đồ trình tự thì chúng ta đã hiểu hơn về sự tương tác giữa các đối tượng trong hệ thống Chúng ta có thể dần dần xác định được hành vi ứng xử của các đối tượng, nghĩa là xác định các hàm thành phần của các lớp
Nghiên cứu các biểu đồ trình tự chúng ta nhận thấy:
Dựa vào nguyên lý nêu trên và căn cứ vào các biểu đồ trình tự ở hình 5-5, 5-6, 5-7, lớp
HeThong sẽ có những hàm thành phần như sau:
Hình 5-8 Các thao tác của hệ thống được ghi nhận vào lớp có tên là HeThong
Khi phát triển biểu đồ trình tự cho chức năng "Thanh toán bằng séc", các hàm như makeCheckPayment() và handleCheckReply() sẽ được thêm vào lớp HBH.
1 Để đơn gian, trong giai đoạn này chúng ta có thể bỏ qua các đối số của các hàm thành phần của các lớp
Biểu đồ trạng thái
Bước nghiên cứu tiếp theo sau biểu đồ trình tự là biểu đồ trạng thái (State
Diagram, State Machine Diagram, State Chart Diagram )
Biểu đồ trạng thái cung cấp thông tin về các trạng thái khác nhau của đối tượng, thể hiện quá trình chuyển đổi giữa các trạng thái và hoạt động của đối tượng trong từng trạng thái Nó mô tả chu kỳ hoạt động của đối tượng, các hệ thống con và toàn bộ hệ thống, từ giai đoạn khởi tạo cho đến khi kết thúc.
Các trạng thái mà các đối tượng có thể có,
Các sự kiện bao gồm thông điệp nhận được, các lỗi có thể xảy ra và điều kiện có thể trở thành đúng, ảnh hưởng đến trạng thái và dẫn đến sự biến đổi của chúng theo thời gian.
Biểu đồ trạng thái là công cụ hiệu quả để mô hình hóa hành vi động của các lớp đối tượng trong dự án Mặc dù không cần thiết phải tạo biểu đồ cho tất cả các lớp, nhưng với những lớp có nhiều hành vi động và trạng thái khác nhau, việc sử dụng biểu đồ trạng thái sẽ giúp hiểu rõ hơn về hệ thống.
5.3.1 Trạng thái và sự biến đổi trạng thái
Mỗi đối tượng trong hệ thống đều trải qua một chu kỳ sống và ở mỗi thời điểm, chúng đều có trạng thái cụ thể Chẳng hạn, người bán hàng trong hệ thống HBH có thể đang thực hiện giao dịch, hoặc phiên bán hàng đã được thanh toán.
Trạng thái là một trong các điều kiện có thể để đối tượng tồn tại, là kết quả của một hoạt động trước đó của đối tượng
Trạng thái của đối tượng thường được mô tả trong hình chữ nhật góc tròn và được xác định bởi:
Tên gọi trạng thái, thường bắt đầu bằng động từ,
Biến trạng thái mô tả các giá trị hiện thời của trạng thái,
Hoạt động là hành vi mà một đối tượng thực hiện khi ở trong một trạng thái nhất định Cấu trúc của hoạt động trong trạng thái được mô tả theo hình thức: event_name argument_list ‘/’ action_exp.
Trong đó, event_name: Tên của sự kiện, có thể là một trong các sự kiện chuẩn: exit
Trong lập trình, "thoát ra" (exit) và "nhập vào" (entry) là hai khái niệm quan trọng Danh sách các sự kiện (argument_list) chứa những thông tin cần thiết cho quá trình xử lý, trong khi những hoạt động cần thực hiện (action_exp) bao gồm các lời gọi hàm và thao tác trên các biến trạng thái Việc hiểu rõ các khái niệm này giúp tối ưu hóa hiệu suất và tính chính xác của chương trình.
Ví dụ: trạng thái Login (đăng nhập hệ thống) được mô tả trong UML:
Login LoginTime = CurrentTime entry / type “login” exit / login(UserName, Password) do / get UserName do / get Password help / display help
Khi hệ thống ở trạng thái Login, biến LoginTime được gán với CurrentTime của máy tính Để vào trạng thái này, người dùng cần gõ từ "login" và để thoát, phải gọi hàm login(UserName, Password) Trong trạng thái này, hệ thống nhận vào UserName và Password, đồng thời cung cấp sự trợ giúp hiển thị thông tin cần thiết.
Khi không cần mô tả chi tiết thì có thể chỉ cần tên gọi để xác định trạng thái trong các biểu đồ
Có hai trạng thái đặc biệt là trạng thái bắt đầu được ký hiệu là: và trạng thái kết thúc, được ký hiệu là
Biểu đồ trạng thái thường bắt đầu với trạng thái khởi đầu, trong khi trạng thái kết thúc có thể xuất hiện hoặc không, tùy thuộc vào chu kỳ hoạt động của các đối tượng.
Biểu đồ thể hiện sự biến đổi trạng thái của đối tượng thông qua các sự kiện xảy ra Khi có một hay nhiều sự kiện xuất hiện, trạng thái của đối tượng sẽ thay đổi, cho thấy mối quan hệ giữa các trạng thái khác nhau Sự chuyển trạng thái này là yếu tố quan trọng trong việc hiểu rõ cách thức mà các trạng thái tương tác với nhau.
Sự chuyển trạng được thể hiện trong biểu đồ bằng mũi tên có nhãn là sự kiện, thao tác
Hàm có đối số và điều kiện cầm canh (guard) cho phép sự chuyển trạng diễn ra một cách linh hoạt Sự chuyển trạng này có thể mang tính đệ quy, tức là trong một số điều kiện nhất định, một đối tượng có thể trở về trạng thái ban đầu của nó.
5.3.2 Xác định các trạng thái và các sự kiện Để xác định được các trạng thái và các sự kiện chúng ta cần trả lời cho các câu hỏi sau:
Một đối tượng có thể ở những trạng thái nào? Liệt kê tất cả các trạng thái có thể có trong hệ thống của mỗi đối tượng
Các sự kiện có thể xuất hiện và làm biến đổi trạng thái của đối tượng Từ những sự kiện này, chúng ta có thể xác định các trạng thái khác nhau của đối tượng.
Những trạng thái mới có thể xuất hiện khi một đối tượng chuyển đổi từ trạng thái này sang trạng thái khác do sự tác động của các sự kiện xác định Mỗi trạng thái mang đến những hoạt động đặc trưng cho đối tượng, phản ánh sự thay đổi trong cách thức hoạt động và tương tác của nó.
Sự tương tác giữa các đối tượng là gì? Sự tương tác giữa các đối tượng thường gắn chặt với các trạng thái của đối tượng
Có những sự kiện và trạng thái không thể chuyển đổi, chẳng hạn như việc khách hàng thanh toán bằng thẻ tín dụng không hợp pháp, dẫn đến việc giao dịch không thể thực hiện.
Cái gì làm cho đối tượng được tạo ra? Đối tượng thường được tạo ra bởi một, hay một số sự kiện
Cái gì làm cho đối tượng bị huỷ bỏ? Đối tượng thường được loại bỏ khi không còn cần thiết nó nữa
5.3.3 Xây dựng biểu đồ trạng thái
Biểu đồ trạng thái thể hiện cách các đối tượng phản ứng với sự kiện và mô tả sự biến đổi trạng thái của chúng theo từng sự kiện.
Biểu đồ hoạt động
Biểu đồ hoạt động (Activity Diagram) trong UML gần giống với lưu đồ (Flow
Biểu đồ hành động là công cụ quen thuộc trong phân tích thiết kế có cấu trúc, giúp chỉ ra 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 Nó mô tả rõ ràng các hành động và kết quả tương ứng của những hành động đó.
Nhấn mạnh hơn về công việc thực hiện khi cài đặt một thao tác của từng đối tượng,
Biểu đồ hoạt động tương tự như biểu đồ trạng thái, nhưng chủ yếu tập trung vào việc mô tả các hoạt động và thao tác cần thực hiện, cũng như những kết quả đạt được từ việc thay đổi trạng thái của các đối tượng.
Trạng thái trong biểu đồ hành động đại diện cho các hoạt động hiện tại, và sẽ chuyển sang trạng thái tiếp theo khi hành động ở trạng thái trước đó được hoàn thành.
Trạng thái và sự chuyển trạng
Trạng thái và sự chuyển đổi trạng thái được ký hiệu và cách sử dụng hoàn toàn giống như trong biểu đồ trạng thái đã nêu ở trên
Nút quyết định và rẽ nhánh
Khi một đối tượng hoạt động, nó có thể chuyển đổi giữa các trạng thái khác nhau tùy thuộc vào các điều kiện và sự kiện quyết định Các điều kiện này thường được biểu diễn dưới dạng biểu thức Boolean Trong UML, nút quyết định rẽ nhánh được thể hiện bằng hình thoi, với các đường rẽ nhánh đi kèm điều kiện lựa chọn, như minh họa trong hình 5-14.
Hình 5-14 Nút rẽ nhánh trong biểu đồ hành động
Thanh tương tranh hay thanh đồng bộ
Trong hệ thống, nhiều luồng hành động có thể bắt đầu hoặc kết thúc đồng thời Trong UML, thanh đồng bộ được biểu diễn bằng đoạn thẳng đậm, giúp kết hợp các luồng hành động đồng thời và phân nhánh cho những luồng có khả năng thực hiện song song.
Để minh họa cho quá trình “Đun nước và pha một tách chè Nipton”, chúng ta có thể vẽ biểu đồ hành động Trong đó, một số hoạt động có thể được thực hiện song song, giúp tối ưu hóa thời gian và nâng cao hiệu quả trong việc chuẩn bị đồ uống này.
“Đun nước”, “Tìm một gói chè Nipton”, “Tìm tách”, v.v Biểu đồ hành động cho các hoạt động trên có thể mô tả như hình 5-15
Hình 5-15 Biểu đồ hành động “Đun nước và pha chè”
Pha thêm sữa Đổ nước vào ấm đun nước
Tìm một gói chè Nipton
Tìm tách Đun nước sôi
Bỏ gói chè vào tách Đổ nước sôi vào tách có chè
Tuyến công việc, hay còn gọi là đường bơi, được sử dụng để phân chia các hoạt động theo nhóm đối tượng hoặc theo tuyến hoạt động của từng đối tượng Tương tự như trong một cuộc thi bơi, mỗi vận động viên chỉ được phép bơi trong một tuyến đã được xác định Trong hệ thống phần mềm, mỗi đối tượng cũng hoạt động theo tuyến đã được chỉ định, nhưng điểm khác biệt là giữa các tuyến này có sự chuyển đổi thông tin lẫn nhau.
Khi khách hàng chọn thanh toán bằng thẻ tín dụng, người bán sẽ nhận thẻ từ khách và chuyển cho bộ phận kiểm duyệt Nếu thẻ hợp lệ, số tiền mua hàng sẽ được trừ từ thẻ và thẻ sẽ được trả lại cho khách Các bước này được thể hiện trong biểu đồ hành động như hình 5-16.
Biểu đồ hành động thể hiện các hành động cụ thể của từng đối tượng và hướng dẫn cách thực hiện các công việc nghiệp vụ thông qua các dòng công việc, phù hợp với tổ chức của các đối tượng.
Hình 5-16 Các tuyến công việc trong biểu đồ hành động
Sử dụng Rational Rose để tạo lập biểu đồ trình tự
Tạo lập ba biểu đồ trình tự như hình 5-5, 5.6, 5.7
Thực hiện một số khai báo đặc tả chi tiết:
:KháchHàng :Người bán hàng :CreaditAuthorizationService HBH
+ Gán tệp vào biểu đồ trình tự
+ Bổ sung thông điệp vào biểu đồ trình tự
+ Sắp xếp lại các thông điệp
+ Đánh số lại các thông điệp
+ Ánh xạ đối tượng vào lớp
+ Gán trách nhiệm cho các đối tượng.
Sử dụng Rational Rose để tạo lập biểu đồ trạng thái
Rational Rose hỗ trợ việc tạo lập nhanh chóng các biểu đồ trạng thái Tương tự như các loại biểu đồ khác, người dùng có thể tạo mới biểu đồ trạng thái trong Rose bằng hai phương pháp khác nhau.
1 Nhấn chuột trái ở mục Browser trong thanh thực đơn chính và chọn State Machine Diagram
2 Nhấn chuột trái ở biểu tượng của Logical View hoặc Use Case View ở danh sách trình duyệt, rồi nhấn chuột phải để chọn New > StateChart Diagram
Tất cả các biểu đồ đã được tạo lập có thể được mở, in, xoá, đổi tên, hoặc bổ sung thêm các thành phần bằng cách chọn biểu đồ trong Logical View hoặc Use Case View Để thực hiện, chỉ cần nhấn chuột trái vào biểu đồ tương ứng, sau đó nhấn chuột phải để chọn chức năng mong muốn Để mở một biểu đồ đã tạo trước đó, bạn chỉ cần nhấn đúp chuột trái vào tên biểu đồ trong danh sách trình duyệt bên trái màn hình.
Tạo lập biểu đồ trạng thái như hình 5-10, 5-12, 5-13
Xây dựng biểu đồ trạng thái cho lớp DigitalWatch (đồng hồ điện tử) bao gồm hai hàm chính: modeButton() để thay đổi chế độ chỉnh thời gian giữa giờ và phút, và inc() để tăng một đơn vị thời gian tương ứng với chế độ hiện tại Khi sử dụng hàm inc(), nếu giá trị giờ đạt 24, nó sẽ quay lại 1, và tương tự, nếu phút đạt 60, nó cũng sẽ trở về 1.
Nó có ba trạng thái và cách chuyển trạng được mô tả như sau:
+ Trạng thái Display: trong đó hiển thị thời gian hiện thời: do /display currentTime
+ Khi NSD nhấn vào modeButton thì chuyển sang trạng thái Set Hours (Đặt lại giờ), trong đó thực hiện: do / display hours
+ Khi NSD nhấn tiếp vào modeButton thì chuyển sang trạng thái Set Minute (Đặt lại phút), trong đó thực hiện: do / display minutes
Khi người dùng nhấn nút modeButton lần thứ ba, thiết bị sẽ trở về trạng thái ban đầu Từ trạng thái hiển thị, người dùng có thể tiếp tục chuyển sang trạng thái tiếp theo bằng cách nhấn nút modeButton.
Trong hai trạng thái Set Hours, Set Minute nếu nhấn inc thì thuộc tính hours, minute của đồng hồ sẽ được tăng lên một
(Chi tiết về cách xây dựng biểu đồ tương tác tham khảo trong [17, 22])
Trong quá trình phát triển phần mềm, việc mô tả tóm tắt các chức năng và tính chất đặc trưng của biểu đồ trong cửa sổ Documentation là rất quan trọng Thông tin này giúp theo dõi và hiểu biết về các biểu đồ Để mở cửa sổ Documentation, người dùng có thể chọn từ thực đơn View, sau đó viết tài liệu đặc tả và chú thích cho các hoạt động và khái niệm cơ bản trong kết quả phân tích và thiết kế Đây là một yêu cầu bắt buộc trong công nghệ phần mềm.
Bài tập và câu hỏi
5.1 Hãy cho biết những mệnh đề sau đúng hay sai (true /false), giải thích tại sao?
+ Các sự kiện độc lập cũng có thể xảy ra đồng thời
+ Một lớp có thể có trạng thái khởi đầu và kết thúc
+ Không nhất thiết phải có trạng thái cho một đối tượng
+ Cần phải xây dựng biểu đồ trạng thái cho tất cả các lớp trong hệ thống
+ Hành vi của hệ thống được thể hiện trong các biểu đồ trình tự thông qua sự tương tác của các đối tượng với nhau
Các sự kiện kích hoạt hệ thống hoạt động, và hệ thống này được thiết lập để phản hồi lại các sự kiện do các tác nhân tạo ra.
+ Biểu đồ trạng thái được sử dụng để sinh mã tự động cho chương trình
5.2 Xây dựng biểu đồ trạng thái cho ca sử dụng “Đặt lại giờ, phút, giây cho đồng hồ điện tử”
5.3 Xây dựng biểu đồ trạng thái cho ca sử dụng “Đăng ký môn học”
5.4 Xây dựng biểu đồ trình tự mô tả ca sử dụng “Thu tiền bằng séc” của hệ thống bán hàng
5.5 Thiết lập biểu đồ trình tự và biểu đồ trạng thái cho lớp chính trong ca sử dụng
“Cho mượn sách” của hệ thống “Quản lý thư viện” (Tiếp theo của bài tập 4.3)
5.6 Thiết lập biểu đồ trình tự và biểu đồ trạng thái cho lớp chính trong ca sử dụng
“Nhận trả sách” của hệ thống “Quản lý thư viện” (Tiếp theo của bài tập 4.3)
5.7 Xây dựng biểu đồ trình tự mô tả sự tương tác giữa các lớp đối tượng trong ca sử dụng “Rút tiền tự động” trong “Hệ thống rút tiền tự động ATM (Automatic Teller Machine)” (Tiếp theo của bài toán 4.4)
5.8 Chọn từ danh sách dưới đây những thuật ngữ thích hợp để điền vào các chỗ [(…)] trong đoạn văn mô tả về biểu đồ tương tác
Xây dựng là quá trình gán trách nhiệm cho các thành phần trong dự án Từ giai đoạn này, người thiết kế có thể phát hiện thêm các yêu cầu và thao tác cần thực hiện cho từng thành phần Do đó, xây dựng trở thành nền tảng cho các bước tiếp theo trong quá trình phát triển phần mềm.
Chọn câu trả lời: a lớp b các đối tượng c biểu đồ tương tác
THIẾT KẾ CÁC BIỂU ĐỒ CỘNG TÁC VÀ BIỂU ĐỒ THÀNH PHẦN CỦA HỆ THỐNG
Các biểu đồ cộng tác
Trong chương 5, chúng ta đã khẳng định rằng các hoạt động của hệ thống có thể được mô tả trực quan thông qua các biểu đồ tương tác UML xác định hai loại biểu đồ tương tác chính là biểu đồ trình tự và biểu đồ cộng tác.
Biểu đồ cộng tác tương tự như biểu đồ trình tự, nhưng nó nhấn mạnh sự tương tác giữa các đối tượng trong một ngữ cảnh và không gian làm việc cụ thể.
Biểu đồ cộng tác là một loại đồ thị thể hiện các đối tượng và mối liên kết giữa chúng, trong đó các đỉnh đại diện cho các đối tượng, còn các cạnh biểu thị sự trao đổi thông điệp giữa các đối tượng này.
Trong hệ thống bán hàng, khi khách hàng thanh toán bằng tiền mặt, người bán cần ghi lại số tiền khách đưa Hệ thống HBH nhận thông điệp makePayment(soTien), trong đó soTien là số tiền khách hàng đưa, thường lớn hơn giá trị hàng hóa, và hệ thống phải tính toán số dư để trả lại Để thực hiện thanh toán, HBH gửi thông điệp tương tự đến phiên bán hàng, dẫn đến việc tạo đối tượng ThanhToan theo thông điệp create(soTien) để hoàn tất giao dịch Biểu đồ trình tự trong Hình 5-4 minh họa quá trình trao đổi thông điệp theo thời gian, trong khi biểu đồ cộng tác sẽ thể hiện mối tương tác này trong ngữ cảnh thực hiện công việc.
Hình 6-1 Biểu đồ cộng tác để thực hiện thanh toán tiền mặt thông điệp đầu tiên
Hướng thông điệp thông điệp đầu tiên bên trong hệ thống Đối tượng đường liên kết
Biểu đồ trên được đọc như sau:
1 Thông điệp đầu makePayment(soTien) (chính là lời gọi hàm) được gửi tới một đối tượng :HBH của HBH
2 Đối tượng :HBH gửi tiếp thông điệp tới một đối tượng của PhienBanHang là :PhienBanHang Hàm này được đánh số là 1
PhienBanHang sử dụng toán tử tạo lập của lớp ThanhToan để khởi tạo một đối tượng ThanhToan dựa trên thông điệp created(soTien), nhằm thực hiện nhiệm vụ thu tiền Thông điệp này được gán số hiệu 1.1.
Qua đó có thể khẳng định: biểu đồ cộng tác của một hoạt động thể hiện thuật toán để thực thi hành động đó
Trước khi thiết kế biểu đồ cộng tác cho các hoạt động trong hệ thống, cần chú ý đến các ký hiệu, cách biểu diễn thông điệp và những quy ước quan trọng.
(1) Thể hiện giá trị trả lại (return value)
Trong lập trình, một số thông điệp được gửi đến đối tượng yêu cầu trả lại giá trị cho đối tượng gửi Giá trị này có thể được chỉ định thông qua việc gán cho một tên biến và tên của thông điệp đó, thực chất là một lời gọi hàm có kiểu giá trị trả lại.
C, đó là những hàm có kiểu trả lại khác void)
Cú pháp chung của thông điệp này có dạng:
ReturnVariableName := message(parameter:ParameterType): ReturnType
Hình 6-2 Thông điệp có giá trị trả lại
(2) Thể hiện các thông điệp lặp
Một đối tượng có khả năng gửi một thông điệp cho một đối tượng khác nhiều lần Thông điệp lặp lại này được biểu diễn bằng cách sử dụng dấu ‘*’ trước nội dung thông điệp.
Kiểu giá trị trả lại msg()
Biến giá trị trả lại
Hình 6-3 Thông điệp lặp lại với số lần không xác định
Hình 6-4 Thông điệp lặp lại với số lần xác định
Có một số cách khác nhau để biểu diễn cho chu trình lặp, ví dụ thay vì viết
Khi một đối tượng nhận thông điệp, chẳng hạn như HBH nhận được msg() như hình 6-4, lớp HBH cần phải có hàm thành phần msg() để xử lý thông điệp đó.
Biểu đồ cộng tác minh họa thuật toán hoạt động của hệ thống Dựa vào biểu đồ cộng tác trong hình 6-4, lập trình viên có thể xây dựng hàm msg() cho lớp HBH trong ngôn ngữ C như sau: void msg() { for(int i = 1; i < 11; i++) dong[i] = phienBH.dongBanTiep(); }.
Hàm này gọi tới hàm dongBanTiep() của lớp PhienBanHang thông qua đối tượng phienBH để đọc liên tiếp 10 dòng bán hàng
Lưu ý: Một đối tượng có thể gửi thông điệp cho chính nó, nghĩa là thông điệp có thể quay vòng tròn
(3) Tạo lập đối tượng mới
UML sử dụng thông điệp create() để tạo ra một đối tượng mới, tức là một thể hiện của một lớp Trong biểu đồ, có thể bổ sung ký tự bên cạnh đối tượng nhận thông điệp để chỉ rõ điều này.
:HBH :PhienBanHang msg() 1: *dong := dongBanTiep()
Hình 6-5 Tạo lập đối tượng mới
(4) Quy tắc đánh số các thông điệp
(i) Thông điệp đầu không được đánh số
(ii) Những thông điệp được gửi tới cho các đối tượng trực tiếp được đánh số tăng dần 1: , 2: , v.v
(iii) Các thông điệp gửi tiếp cho các đối tượng tiếp theo được đánh số theo quy tắc “dấu chấm” (‘.’)
Hình 6-6 Đánh số các thông điệp
Các điều kiện gửi thông điệp có thể khiến thông điệp bị cầm canh và chỉ được gửi đến đối tượng khác khi thỏa mãn một điều kiện nhất định Điều kiện này được đặt trong cặp ngoặc ‘[‘ và ‘]’.
Hình 6-7 Các thông điệp được gửi đi có điều kiện Biểu đồ trên thể hiện:
+ Thông điệp số 1a được gửi cho :B nếu điều kiện condition thoả mãn,
+ Ngược lại, nếu condition sai (non condition) thì thông điệp 1b sẽ được gửi đến cho :D
(6) Các thông điệp gửi cho một tập (nhiều) các đối tượng
UML ký hiệu tập các thể hiện (đối tượng) như là một kho các đối tượng dạng:
Ký hiệu tập các đối tượng phienBH của lớp PhienBanHang
Ví dụ: Đối tượng :PhienBanHang gửi thông điệp next() tất cả các phienBH và thông điệp print() cho một :DongBanHang bất kỳ
Hình 6-8 Gửi thông điệp cho nhiều đối tượng
Thiết kế các biểu đồ cộng tác và các lớp đối tượng
Nhiệm vụ chính của pha thiết kế là xây dựng các biểu đồ cộng tác để mô tả chính xác hoạt động của hệ thống và từ đó thiết kế chi tiết các lớp Một trong những thách thức lớn nhất là xác định cách gán trách nhiệm cho các đối tượng Chương này sẽ thảo luận về nguyên lý tổng quát trong việc gán vai trò cho các đối tượng, còn được gọi là mẫu gán trách nhiệm.
Việc tạo lập các biểu đồ cộng tác phụ thuộc vào các kết quả trong pha phân tích:
Mô hình khái niệm cho phép người thiết kế xác định các lớp tương ứng với từng khái niệm trong hệ thống Các đối tượng trong các lớp này tương tác và được thể hiện qua các biểu đồ tương tác như biểu đồ trình tự và biểu đồ trạng thái.
Các hợp đồng hoạt động trong hệ thống giúp người thiết kế xác định rõ trách nhiệm và các điều kiện cần thiết, bao gồm các điều kiện trước (Pre-condition) và sau (Post-condition), thông qua các biểu đồ tương tác.
Các ca sử dụng cốt yếu và thực tế giúp người thiết kế thu thập thông tin quan trọng về các nhiệm vụ mà biểu đồ tương tác cần đáp ứng.
: PhienBanHang :DongBanHang sLi: DongBanHang Một đối tượng
6.2.1 Ca sử dụng thực tế
Trong pha phân tích yêu cầu, các ca sử dụng thường ít liên quan đến kỹ thuật cài đặt và giao diện sử dụng Bài viết này sẽ thảo luận về hai loại ca sử dụng quan trọng, đó là ca sử dụng cốt yếu và ca sử dụng thực tế.
Một ca sử dụng được gọi là cốt yếu nếu nó mô tả quá trình hoạt động chủ yếu và các động cơ thúc đẩy những hoạt động đó
Ca sử dụng được coi là thực tế khi nó mô tả một quy trình hoạt động dựa trên các thiết kế thực tế, được ủy thác để thực hiện theo công nghệ đầu vào và đầu ra đã được xác định trước.
Ca sử dụng thực tế là một thiết kế cụ thể cho một ca sử dụng, trong đó đã xác định rõ ràng các kỹ thuật vào/ra và hỗ trợ cho việc cài đặt.
Trong một tình huống thực tế, ca sử dụng Thanh toán tiền mặt có thể được mô tả là phương thức giao dịch phổ biến, nơi khách hàng thanh toán trực tiếp bằng tiền mặt tại điểm bán Điều này thường xảy ra trong các cửa hàng nhỏ, quán cà phê hoặc chợ truyền thống, nơi mà việc thanh toán qua thẻ hoặc ví điện tử chưa phổ biến Thanh toán tiền mặt mang lại sự tiện lợi và nhanh chóng, đồng thời giúp người tiêu dùng kiểm soát tốt hơn chi tiêu của mình.
Ca sử dụng: Thanh toán tiền mặt (Buy Items with Cash)
Tác nhân: Người mua (khách hàng), người bán hàng
Mục đích: Ghi nhận các thông tin về phiên bán hàng và thu tiền hàng
Sau khi hoàn tất việc chọn hàng, người mua sẽ mang giỏ hàng đến quầy thanh toán Tại đây, người bán sẽ ghi nhận thông tin về các sản phẩm và thu tiền bằng tiền mặt Sau khi hoàn tất thanh toán, khách hàng có thể mang hàng ra khỏi cửa hàng.
Trên cơ sở khảo sát bài toán thực tế, người thiết kế có thể xây dựng màn hình (màn hình giao diện) thực hiện nhiệm vụ trên như sau:
Hình 6-9 Màn hình giao diện của ca sử dụng thực tế “Bán hàng”
Kịch bản mô tả ca sử dụng thực tế trên được viết cụ thể như sau:
Balance Cửa hàng Sao Mai: Bán hàng - ×
Hoạt động của tác nhân Hoạt động của hệ thống
1 Ca sử dụng bắt đầu khi khách đưa hàng đến quầy trả tiền
2 Với mỗi mặt hàng, người bán nhập vào cửa sổ A mã upc Nếu số lượng mua nhiều hơn 1 thì nhập số đó vào cửa sổ E Ấn H (nút Enter Item) sau mỗi lần nhập xong một mặt hàng
3 Bổ sung các thông tin của từng mặt hàng vào phiên bán hàng
Mô tả của mặt hàng vừa nhập vào được hiển thị ở ô F và giá bán ở ô B
4 Khi nhập xong các mặt hàng thì ấn
5 Tính toán và hiển thị tổng số tiền phải trả ở ô C
6 Khách hàng đưa một số tiền để trả tiền mua hàng, người nhập số đó vào ô D và ấn J (nút Make
Payment ), số đó thường lớn hơn total
7 Hệ thống xác định số tiền trả lại cho khách và hiển thị ở ô G
Nhiệm vụ chính của người thiết kế là xác định các lớp đối tượng để thực hiện các yêu cầu của hệ thống Để đạt được điều này, cần thiết kế chi tiết các biểu đồ cộng tác mô tả chính xác từng hoạt động của hệ thống và phân công nhiệm vụ cho các lớp đối tượng.
Trách nhiệm trong hợp đồng được định nghĩa là nghĩa vụ của từng bên liên quan, và hành vi của các bên này gắn liền với trách nhiệm mà họ phải thực hiện.
Nói chung có hai loại trách nhiệm:
1 Các trách nhiệm thực hiện: đó là những hoạt động mà đối tượng thực hiện bao gồm:
Tự động thực hiện cái gì đó,
Khởi động một hoạt động hoặc kích hoạt thao tác của các đối tượng khác là bước đầu tiên trong việc điều khiển và phối hợp hành động giữa các đối tượng khác nhau Việc này giúp tối ưu hóa sự tương tác và hiệu quả trong quá trình thực hiện nhiệm vụ.
2 Những trách nhiệm để biết: những hiểu biết về các đối tượng, bao gồm:
Hiểu biết về dữ liệu riêng được bao gói và bị che giấu,
Hiểu biết về những đối tượng liên quan,
Hiểu biết về những sự vật có thể xuất phát hoặc những tính toán nào đó
Trong hệ thống hướng đối tượng, thông tin được lưu trữ dưới dạng các đối tượng và chỉ được xử lý khi nhận lệnh thực hiện nhiệm vụ Để sử dụng các đối tượng, ngoài việc hiểu các thuộc tính, người dùng cần biết cách giao tiếp với chúng, tức là nắm rõ các hàm thành phần có sẵn Thông tin này thường được thể hiện qua các biểu đồ cộng tác.
Các bước thiết kế biểu đồ cộng tác
Việc tạo ra biểu đồ cộng tác có thể thực hiện như sau:
1 Xác định các trách nhiệm từ các ca sử dụng, mô hình khái niệm (biểu đồ lớp) và các hợp đồng hành động của hệ thống,
2 Gán trách nhiệm cho các đối tượng, quyết định xem đối tượng nào phải thực thi những trách nhiệm trên,
3 Lặp lại hai bước trên cho đến khi gán hết các trách nhiệm trong biểu đồ cộng tác
Lưu ý: Các trách nhiệm của đối tượng sẽ được cài đặt trong lớp của những đối tượng đó bằng các hàm thành phần (phương thức)
Trong UML, trách nhiệm được phân bổ cho các đối tượng thông qua biểu đồ cộng tác, biểu đồ này không chỉ thể hiện sự gán trách nhiệm mà còn mô tả sự cộng tác giữa các đối tượng trong hệ thống.
Thiết kế hệ thống HBH
Trong phần này, chúng ta sẽ áp dụng nguyên tắc GRASP để phân chia trách nhiệm cho các lớp và xây dựng biểu đồ cộng tác Chúng ta sẽ bắt đầu với các mẫu cho hai ca sử dụng: "Thanh toán tiền mặt" và "Khởi động" (Start Up), sau đó sẽ tiếp tục thực hiện tương tự cho các ca sử dụng khác.
Khi thiết kế biểu đồ cộng tác, chúng ta hãy thực hiện theo những hướng dẫn sau:
1 Với mỗi thao tác (hoạt động chính) đã được mô tả trong các hợp đồng của hệ thống nên tạo ra một biểu đồ riêng
2 Nếu biểu đồ này phức tạp thì có thể chia nó thành những biểu đồ đơn giản hơn
3 Sử dụng các hợp đồng trách nhiệm, trong đó dựa vào những điều kiện cần thoả mãn sau khi hoàn thành (post-condition) và các mô tả ca sử dụng để xác định trách nhiệm của các đối tượng trong hệ thống theo mẫu gán trách nhiệm như đã nêu trên Để thực hiện ca sử dụng “Thanh toán tiền mặt và “Khởi động”, hệ thống phải thực hiện: enterItems() (nhập các mặt hàng), endSale() (kết thúc một phiên bán hàng), makePayment() (thanh toán) và startUp() (khởi động) Theo hướng dẫn trên, chúng ta thiết kế các biểu đồ cộng tác cho những thao tác đó
Chúng ta bắt đầu từ bốn biểu đồ như hình 6-19
Hình 6-19 Các thao tác của hệ thống
Biểu đồ cộng tác cho enterItems()
Trước hết chúng ta xem lại hợp đồng thực hiện enterItems() để biết hệ thống phải làm những gì
1 Hiển thị thông tin mô tả và giá bán của mặt hàng được nhập vào
Trong hệ thống, các đối tượng không có trách nhiệm hiển thị thông tin Thay vào đó, các đối tượng giao diện có thể đảm nhiệm công việc này bằng cách truy cập vào cơ sở dữ liệu (CSDL) về các mặt hàng và gửi thông điệp chứa thông tin tương ứng đến các đối tượng đang hoạt động.
2 Tạo lập phiên bán hàng mới
Theo hợp đồng, khi bắt đầu phiên bán hàng đầu tiên, cần phải tạo lập phiên bản bán hàng mới Trách nhiệm này thuộc về HBH, và nhiệm vụ của họ là ghi lại tất cả các phiên bán hàng.
Mỗi khi phiên Bán Hàng được tạo mới, nó bắt đầu như một tập rỗng và sau đó được bổ sung các dòng Bán Hàng khi nhập xong mỗi mặt hàng Việc áp dụng các mẫu gán trách nhiệm cho phép gán việc tạo lập dòng Bán Hàng mới cho phiên Bán Hàng một cách hợp lý.
3 Xác định các thông tin mô tả và giá bán
Sau khi các dòng bán hàng được tạo lập, chúng cần được bổ sung vào phiên bán hàng đang hoạt động bằng cách gửi thông điệp add() cho các dòng bán hàng mới nhập vào Những dòng bán hàng này phải được xác định từ danh mục mặt hàng và mô tả mặt hàng Để có được thông tin cần thiết, hệ thống phải gửi thông điệp specification(upc) nhằm xác định mô tả mặt hàng, sau đó thực hiện các bước enterItems(), startUp(), makePayment() và endSale().
Hàm HBH bao gồm các chức năng như enterItems(), endSale(), makePayment() và startUp() Đối với hàng hóa có mã UPC thuộc DanhMucMatHang, đối tượng sẽ gửi thông điệp find(upc) để tìm kiếm trong tập hợp các mô tả mặt hàng có mã UPC đó.
Dựa vào những thảo luận như trên, biểu đồ cộng tác sẽ được xây dựng như sau:
Hình 6-20 Biểu đồ cộng tác cho enterItems()
Tầm nhìn của các lớp
Trong hệ thống, các đối tượng tương tác với nhau thông qua việc trao đổi thông điệp, chủ yếu là các lời gọi hàm Cụ thể, khi cần xác định thông tin về mặt hàng có mã UPC, hệ thống sẽ gửi lời gọi hàm specification(upc) đến đối tượng :DanhMucMatHang Đối tượng này sau đó sẽ tiếp tục gửi lời gọi hàm find(upc) đến :MoTaMatHang để lấy thông tin chi tiết.
Để thu thập thông tin từ những người khác, một cá nhân cần có khả năng nhận diện và hiểu rõ những gì mình cần Việc này không chỉ đòi hỏi sự chú ý mà còn cần khả năng phân tích để xác định thông tin quan trọng.
Trong thiết kế hướng đối tượng, sự liên kết có liên quan chặt chẽ với khái niệm khả năng nhìn thấy được của các đối tượng
Nếu :A có thể nhìn thấy :B thì phải có một liên kết giữa hai đối tượng đó, nghĩa là giữa hai lớp tương ứng có quan hệ kết hợp
Nếu giữa hai đối tượng :A và :B hiện thời có liên kết với nhau thì một trong hai đối tượng đó có một đối tượng nhìn thấy đối tượng kia
Về sự trao đổi thông điệp giữa các đối tượng có thể phát biểu chính xác như sau:
3.1: create(mt,n) Để đối tượng :A có thể gửi một thông điệp cho đối tượng :B thì lớp A phải được liên kết với lớp B Để đối tượng :A gửi được thông điệp cho đối tượng :B thì đối tượng :A phải nhìn thấy được đối tượng :B
Có bốn cách để đối tượng A nhìn thấy được đối tượng :B
1 Tầm nhìn thuộc tính: :B là thuộc tính của :A
2 Tầm nhìn tham số: :B là tham số của một hàm nào đó của :A
3 Tầm nhìn khai báo cục bộ: :B được khai báo là đối tượng cục bộ trong định nghĩa hàm của :B
4 Tầm nhìn toàn cục: :B là toàn cục
Dựa vào phạm vi quan sát của các đối tượng trong biểu đồ, chúng ta có thể xác định các đặc tính private, protected và public cho các thuộc tính và hàm thành phần trong các lớp đối tượng Việc này giúp quản lý quyền truy cập và bảo mật dữ liệu hiệu quả hơn trong lập trình hướng đối tượng.
Biểu đồ cộng tác cho endSale
Có thể chọn HBH để điều khiển thao tác này của hệ thống Hợp đồng của thao tác này yêu cầu:
PhienBanHang.isComplete được gán trị true khi kết thúc nhập dữ liệu
Như vậy, hệ HBH có thể gửi thông điệp becomeComplete() cho PhienBanHang để đặt thuộc tính isComplelet nhận giá trị true
Hình 6-21 Biểu đồ cộng tác thể hiện Kết thúc nhập dữ liệu endSale()
Biểu đồ cộng tác cho makePayment
Chúng ta sẽ xem HBH như một bộ điều khiển Trong phần thảo luận về mẫu gán trách nhiệm nhằm đảm bảo sự kết nối giữa các lớp yếu nhưng có độ cố kết cao, trách nhiệm tạo lập đối tượng ThanhToan được gán cho lớp PhienBanHang, không phải lớp HBH Biểu đồ cộng tác cho thao tác makePayment() được mô tả lại như sau: becomeComplete(){ isComplete = true;
Theo mẫu móc nối yếu Qua bộ điều khiển
Hình 6-22 Biểu đồ cộng tác cho makePayment()
Biểu đồ này đáp ứng những điều kiện sau:
Một đối tượng của lớp ThanhToan đảm nhận việc thanh toán,
ThanhToan được kết hợp với PhienBanHang
Ghi nhận những phiên bán hàng đã kết thúc
Sau mỗi phiên bán hàng, hệ thống cần ghi lại ký sự các phiên bán theo yêu cầu của Công ty Theo kinh nghiệm của chuyên gia, trách nhiệm này có thể được giao cho hàm addSale().
CuaHang sau khi đã gán trách nhiệm makePayment() cho PhienBanHang Biểu đồ ở hình 6-22 được bổ sung thành:
Hình 6-23 Biểu đồ cộng tác cho makePayment() và ghi nhận thông tin đã bán
Biểu đồ cộng tác cho ca sử dụng StartUp
Hầu hết các hệ thống đều có ca sử dụng "Khởi động", thực hiện các thao tác khởi tạo giá trị cho ứng dụng khi bắt đầu Mặc dù đây là thao tác đầu tiên cần thực hiện, chúng ta sẽ thiết kế sau để đảm bảo tất cả thông tin liên quan đến các hoạt động tiếp theo của hệ thống được phát hiện đầy đủ.
Biểu đồ cộng tác của StartUp cho thấy những khả năng phát sinh khi đối tượng trong miền ứng dụng được tạo ra Điều này có nghĩa là trong hệ thống bán hàng, trách nhiệm thực hiện phương thức create() cần được gán cho các lớp chính như HBH hoặc CuaHang.
Chúng ta chọn CuaHang bởi vì HBH đã được chọn làm bộ điều khiển cho các hoạt động của cả hệ thống
Căn cứ vào hợp đồng của StartUp và những thảo luận ở trên, ta có thể thiết kế biểu đồ cộng tác cho StartUp như sau: makePayment(soTien)
1 Bắt đầu gửi thông điệp create() cho CuaHang,
Thiết kế chi tiết các biểu đồ lớp
Khi tạo ra các biểu đồ cộng tác, chúng ta đã ghi nhận những phương thức (hàm) tương ứng và được gán vào cho các lớp (như hình 6-22, 6-23, 6-24, v.v.)
Các lớp và hàm đã xác định là những thành phần phần mềm đại diện cho các khái niệm trong mô hình khái niệm Dựa vào các lớp phần mềm cùng với biểu đồ khái niệm và biểu đồ cộng tác, chúng ta có thể xây dựng thiết kế chi tiết biểu đồ lớp để truyền đạt thông tin một cách rõ ràng và hiệu quả.
Các lớp, các thuộc tính và các mối quan hệ kết hợp,
Các hàm thành phần (phương thức),
Các kiểu của các thuộc tính,
Tình trạng có thể điều khiển được,
Sự phụ thuộc giữa các lớp
Các bước thực hiện để thiết kế biểu đồ lớp
1 Xác định tất cả các lớp có các đối tượng tương tác với nhau Điều này thực hiện được thông qua phân tích các biểu đồ tương tác
2 Vẽ chúng trong một biểu đồ lớp
3 Xác định thuộc tính của chúng (sao chép từ các khái niệm trong biểu đồ khái niệm) và bổ sung cho đầy đủ
4 Phân tích các biểu đồ cộng tác để xác định các hàm và bổ sung cho các lớp
5 Xác định các kiểu của các thuộc tính và các giá trị trả lại của phép toán
6 Bổ sung những mối liên kết cần thiết để quản lý các quyền truy nhập (khả năng nhìn thấy) của các thuộc tính
7 Bổ sung các quan hệ phụ thuộc dữ liệu
8 Xác định mối quan hệ tổng quát hoá/chi tiết hoá và bổ sung quan hệ kế thừa vào biểu đồ lớp
Trước khi bắt tay thiết kế biểu đồ lớp, chúng ta cần phân biệt mô hình khái niệm (biểu lớp phân tích) với biểu đồ lớp thiết kế
Trong mô hình khái niệm, ví dụ:
Hình 6-25 Hai lớp trong mô hình khái niệm Hai lớp: PhienBanHang và HBH ở đây là các khái niệm trừu tượng
Trong pha thiết kế, các lớp trên là các thành phần của hệ thống
Các bước thiết kế lớp từ 1 đến 5 đã được thực hiện dần từ giai đoạn phân tích và khá đơn giản Bài viết này sẽ tập trung vào việc giới thiệu ba bước cuối cùng để hoàn thiện thiết kế biểu đồ lớp.
6 Bổ sung các mối quan hệ kết hợp và khả năng điều khiển được
Trong hệ thống, giữa hai lớp thường tồn tại các mối quan hệ xác định, phổ biến nhất là quan hệ kết hợp Mỗi đầu của quan hệ này đóng vai trò quan trọng, có thể được thể hiện qua các mũi tên chỉ hướng điều khiển trong thiết kế biểu đồ lớp Khả năng điều khiển, một đặc tính của vai trò, cho thấy mối quan hệ này có thể điều khiển một chiều từ đối tượng của lớp nguồn tới đối tượng của lớp đích Ví dụ, biểu đồ lớp ở hình 6-25 có thể được bổ sung chiều điều khiển như trong hình 6-26.
Hình 6-26 Chỉ rõ hướng điều khiển của vai trò trong biểu đồ lớp
Khả năng điều khiển trong biểu đồ lớp thể hiện sự nhìn thấy các thuộc tính của lớp đích từ lớp nguồn Trong lập trình, điều này được thực hiện bằng cách xây dựng lớp nguồn chứa các đối tượng của lớp đích Ví dụ, trong cài đặt các lớp như hình 6-26, lớp HBH có thuộc tính tham chiếu tới đối tượng của lớp PhienBanHang.
Khả năng điều khiển và mối quan hệ giữa các lớp được thể hiện rõ qua các biểu đồ cộng tác Chúng ta dựa vào các tình huống gợi ý để xác định mối liên kết và khả năng điều khiển từ A đến B.
1 ghi-Nhận 1 PhienBanHang ngayBan: Date gioBan: Time iscomplete: Boolean becomeComplete() makeLineItem() total()
1 ghi-Nhận 1 PhienBanHang ngayBan:Date gioBan: Time iscomplete: Boolean becomeComplete() makeLineItem() total()
:A gửi một thông điệp tới cho :B thì A kết hợp với B theo chiều từ A tới B
A tạo ra một đối tượng của B thì A kết hợp với B theo chiều từ A tới B
A có quan hệ kết nối với B thông qua thuộc tính có giá trị thuộc kiểu B, thì A kết hợp với B theo chiều từ A tới B
:A nhận được một thông điệp trong đó có đối tượng của B đóng vai trò là tham số thì A kết hợp với B theo chiều từ A tới B
Dựa vào những qui ước nêu trên chúng ta thiết kế một phần biểu đồ lớp có đủ các quan hệ kết hợp và chiều điều khiển như hình 6-27
7 Bổ sung các quan hệ phụ thuộc dữ liệu
Trong thiết kế, ngoài khả năng nhìn thấy của các thuộc tính, còn tồn tại ba khả năng khác là tầm nhìn tham số, tầm nhìn khai báo cục bộ và tầm nhìn toàn cục Sự nhìn thấy giữa các lớp được thể hiện qua quan hệ phụ thuộc, được mô tả bằng đường đứt nét có mũi tên, chỉ rõ lớp nguồn phụ thuộc vào lớp đích.
1 Đối tượng của HBH nhận được thông tin mô tả mặt hàng (MoTaMatHang) sau khi nó gửi thông điệp đến cho DanhMucMatHang
Do vậy, MoTaMatHang phải được khai báo cục bộ trong HBH, nghĩa là
HBH phụ thuộc vào MoTaMatHang
2 Tương tự, PhienBanHang nhận được MoTaMatHang như là tham số trong hàm makeLineItem(), nghĩa là MoTaMatHang nằm trong tầm nhìn tham số của PhienBanHang Vậy, PhienBanHang cũng phụ thuộc vào MoTaMatHang
Từ đó chúng ta có biểu đồ lớp cùng quan hệ phụ thuộc như hình 6-28
Chứa 1 MoTaMatHang maSanPham: UPC giaBan: Number moTa: Text
PhienBanHang ngayBan: Date gioBan: Time becomeComplete() makeLineItem() makePayment() total()
CuaHang diaChi: Address tenGoi: String addSale()
Có Được-mô-tả-bởi
Hình 6-27 Thiết kế biểu đồ lớp được bổ sung quan hệ kết hợp
Hình 6-28 Thiết kế biểu đồ lớp được bổ sung quan hệ phụ thuộc
8 Xác định lớp tổng quát và bổ sung các quan hệ kế thừa
Ca sử dụng “Thanh toán” được chia thành các ca sử dụng con bao gồm “Thanh toán bằng thẻ” (makeCreditPayment), “Thanh toán tiền mặt” (makeCashPayment), và “Thanh toán bằng Check” (makeCheckPayment), tùy thuộc vào phương thức thanh toán mà khách hàng lựa chọn.
Hình 6-29 Phân tích tiếp ca sử dụng “Thanh toán” từ hình 3-6
Trong các phần trước, chúng ta đã phân tích ca sử dụng “Thanh toán tiền mặt” và xác định các lớp đối tượng liên quan Tiếp tục phân tích hai ca sử dụng còn lại, chúng ta sẽ tìm kiếm các lớp tương ứng dựa trên kịch bản mô tả Việc này giúp làm rõ hơn cấu trúc và chức năng của từng ca sử dụng trong hệ thống.
Mô tả chi tiết các ca sử dụng trên:
Quản-lý * 1 Được-trả-bởi 1
Chứa 1 MoTaMatHang maSanPham: UPC giaBan: Number moTa: Text
PhienBanHang ngayBan: Date gioBan: Time becomeComplete() makeLineItem() makePayment() total()
CuaHang diaChi: Address tenGoi: String addSale()
Có Được-mô-tả-bởi
Thanh toán bằng thẻ tín dụng
Các tác nhân Hệ thống
1 Ca sử dụng này được bắt đầu thực hiện khi khách được thông báo tổng số tiền phải trả và họ chọn phương thức thanh toán bằng Credit
2 Khách hàng đưa thẻ Credit và thẻ đưa đọc qua đầu đọc
3 Hệ thống phát sinh yêu cầu kiểm tra thẻ
Credit và gửi tới bộ phận dịch vụ kiểm tra thẻ CreditAuthorization Service (CAS) qua modem được gắn với HBH Hệ thống chờ trả lời
4 Khi nhận được kết quả trả lời về tính hợp pháp của thẻ từ CAS, hệ thống ghi lại kết quả trả lời
5 Nếu thẻ Credit hợp lệ thì nó được gửi tới bộ phận tài vụ, Account số tiền và thẻ bị trừ đi số tiền phải trả
Các tác nhân Hệ thống
1 Ca sử dụng này được bắt đầu thực hiện khi khách hàng được thông báo số tiền phải trả và chọn phương pháp thanh toán trả séc (Check)
2 Khách hàng viết Check, đưa Check và xuất trình drivers license (giấy phép sử dụng check) cho người bán hàng
3 Người bán kiểm tra drivers license và
Check và nhấn nút: CheckAuthorization để yêu cầu kiểm tra
4 Hệ thống phát sinh yêu cầu kiểm tra Check và gửi nó cho bộ phận kiểm tra CheckAuthorization Service qua modem gắn với HBH
5 Nhận được kết quả kiểm tra hệ thống ghi lại các thông tin trên Check
6 Hiển thị kết quả xử lý và thông báo cho khách hàng
Do vậy, ngoài những lớp đã phân tích thiết kế ở trên, chúng ta cần bổ sung thêm các lớp có kiên quan:
ThanhToanTienM (CashPayment) ThanhToanThe (CreditPayment), ThanhToanCheck
(CheckPayment) Liên quan đến những lớp này là TheCredit (CreditCard) và Check Ngoài ra còn cần những lớp phục vụ cho việc kiểm duyệt thẻ Credit và Check là
Các lớp ThanhToanTienM, ThanhToanThe và ThanhToanCheck có nhiều điểm tương đồng về tính chất và hành vi, do đó có thể coi chúng là kiểu con (subtype) kế thừa từ lớp ThanhToan Để thực hiện thanh toán bằng thẻ, cần sử dụng TheCredit, trong khi để thanh toán bằng séc, phải có TheCheck Mỗi TheCredit có thể được sử dụng để mua hàng nhiều lần, trong khi mỗi tờ TheCheck chỉ có thể được sử dụng một lần Các mối quan hệ này được thể hiện rõ trong biểu đồ.
Hình 6-30 Các lớp kế thừa của ThanhToan
Một số lưu ý về lớp tổng quát (lớp cơ sở) và các lớp con
Trong mối quan hệ kế thừa giữa các lớp luôn yêu cầu phải thoả mãn hai qui tắc sau:
1 Luật thành viên (Is-a Rule):
Tất cả các thành viên của lớp con (lớp kế thừa) cũng là thành viên của lớp cha (lớp tổng quát hơn)
Tất cả các đối tượng của lớp (kiểu) con đều phải phù hợp 100% về:
+ Các thuộc tính, + Các mối quan hệ với các đối tượng của lớp cha
Hình 6-31 Các lớp kế thừa và luật thành viên, luật 100%
Theo hai luật trên thì mọi đối tượng của các lớp con ThanhToanTienM,
ThanhToanThe và ThanhToanCheck đều có thuộc tính tongSoTien như ở lớp cha và chúng đều có quan hệ kết hợp Trả-cho với lớp PhienBanHang
Trong thiết kế hướng đối tượng, việc thiết lập các lớp tổng quát và kế thừa là rất quan trọng để tạo ra cấu trúc phân cấp giữa các lớp Quan hệ kế thừa giúp tái sử dụng thuộc tính và hàm của lớp cha trong việc thiết kế và triển khai các lớp con.
Thường chúng ta có hai cách thực hiện công việc trên
1 Phân tách một lớp thành nhiều lớp con
2 Gộp một số lớp con thành lớp tổng quát hơn
Câu hỏi đặt ra là với những điều kiện nào thì thực hiện phân tách và những điều kiện nào có thể gộp các lớp lại được?
Nguyên nhân cần phân chia một lớp thành một số lớp con
Khi xét một lớp, ngoài những thuộc tính và hành vi chung, các đối tượng còn có:
1 Một số thuộc tính khác nhau cần được bổ sung vào để tạo thành những lớp con cho đối tượng để có thêm những đặc tính khác ngoài những đặc tính chung của lớp cha
2 Một số quan hệ được bổ sung và khác với lớp đang xét
3 Cần xử lý, thao tác khác nhau ở những lớp con
Để thiết kế hệ thống tính tiền lương cho nhân viên, trước tiên cần phân tích lớp NhanVien với các thuộc tính cơ bản như họ và tên (hoTen) và tuổi (tuoi) Nhân viên được phân chia thành các bộ phận như cán bộ quản lý, bộ phận marketing và bộ phận bán hàng Cách tính lương sẽ được thực hiện dựa trên các tiêu chí cụ thể của từng bộ phận.
+ Cán bộ quản lý tính lương theo chức vụ hay nhiệm vụ được giao,
+ Nhân viên marketing được tính lương theo giờ làm việc trong tháng,
+ Các nhân viên bán hàng được trả lương theo % hoa hồng số tiền bán được hàng
Như vậy, các bộ phận trên, ngoài những thuộc tính chung của NhanVien còn có thêm những thuộc tính khác nhau, lớp QuanLy có thêm thuộc tính chucVu, lớp
Marketing có thêm gioLaoDong và lớp BanHang có thêm soTienBanDuoc để mô tả chính xác các nhân viên trong từng bộ phận Điều này cho phép chúng ta phân chia NhanVien thành các nhóm cụ thể hơn, giúp nâng cao hiệu quả quản lý và tối ưu hóa hoạt động kinh doanh.
QuanLy, Marketing và BanHang như sau:
Hình 6-32 Chia lớp NhanVien thành các lớp con
Trong thiết kế, chúng ta thường gộp các lớp có điểm chung thành lớp tổng quát hoặc chia nhỏ và bổ sung tính chất để tạo lớp con kế thừa Phương pháp này tăng khả năng sử dụng lại, đảm bảo tính mở cao và tính tin cậy cho hệ thống.
Nguyên nhân cần gộp lại thành lớp tổng quát
Khi một số lớp (gọi là lớp con) có những tính chất sau thì có thể gộp chúng lại và tạo ra một lớp tổng quát:
1 Các lớp con cùng thể hiện các phiên bản của một khái niệm tương tự
2 Các lớp con đều thoả hai luật: luật 100% và luật thành viên
3 Các lớp con có một số thuộc tính giống nhau để có thể nhóm lại thành lớp tổng quát hơn
4 Các lớp con đó có một số liên kết chung để có thể đưa chúng vào lớp cha
Thiết kế biểu đồ cộng tác và hoàn thiện thiết kế biểu đồ lớp
Tương tự như các chương trước, chi tiết về cách sử dụng các chức năng của Rose có thể tham khảo ở ([17], [22])
6.5.1 Xây dựng biểu đồ cộng tác
+ Tạo lập biểu đồ cộng tác,
+ Tạo lập, bổ sung các tác nhân, đối tượng vào biểu đồ,
+ Bổ sung các thông điệp (hàm), đặt tên và các hướng điều khiển trong các quan hệ kết hợp,
+ Gán trách nhiệm cho các đối tượng,
+ Ánh xạ đối tượng vào lớp và thao tác vào thông điệp
Thực hiện đối với các biểu đồ cộng tác hình 6-12, 6-15, 6-20, 6-23, 6-24
6.5.2 Hoàn thiện thiết kế biểu đồ lớp
Tiếp theo phần thực hành xây dựng biểu đồ lớp ở chương 4, ở đây tập trung thực hiện bổ sung một số tính chất cho lớp:
+ Bổ sung tham số và đặt đối số cho tham số,
+ Bổ sung lớp tiện ích (Class Utility), lớp tham số tiện ích (Parameterized Class
Utility), lớp tiện ích hiện thực (Instantiated Parameterized Class Utility) và Metaclass
This article provides a detailed description of class specifications, including the assignment of types, stereotypes, and visibility attributes It emphasizes the importance of defining multiplicities and storage properties such as persistent and transient attributes Additionally, it highlights the necessity of incorporating comprehensive attributes and functions for each class to enhance functionality and clarity.
+ Bổ sung những quan hệ: kết hợp, kết nhập, phụ thuộc và kế thừa giữa các lớp
Vẽ các biểu đồ lớp như các hình 6-27, 6-28, 6-30, 6-31
Bài tập và câu hỏi
6.1 Hãy cho biết những mệnh đề sau đúng hay sai (true / false), giải thích tại sao?
+ Biểu đồ cộng tác chính là một đồ thị chỉ ra một số các đối tượng và những sự liên kết giữa chúng
+ Biểu đồ cộng tác của một hoạt động thể hiện thuật toán để thực thi hành động đó
+ Ca sử dụng được xác định trong pha phân tích các yêu cầu hỗ trợ để cài đặt và có liện hệ nhiều với giao diện sử dụng
+ Một lớp được thiết kế tốt là lớp có độ móc nối cao và mức độ cố kết thấp
+ Từ một lớp bất kỳ luôn tạo ra được một lớp con kế thừa từ lớp đó
6.2 Xây dựng biểu đồ cộng tác cho hoạt động “Đăng ký môn học” (tiếp theo bài 5.3)
6.3 Xây dựng biểu đồ lớp đầy đủ cho hệ thống “Quản lý thư viện” (tiếp theo bài 5.5)
6.4 Thiết lập biểu đồ lớp cho “Hệ thống rút tiền tự động ATM” (Tiếp theo của bài toán 5.6) 6.5 Thiết lập biểu đồ lớp cho “Hệ thống mô phỏng hệ thống thang máy”
6.6 Xây dựng biểu đồ lớp cho “Hệ thống quản lý học tập của sinh viên”
6.7 Xây dựng biểu đồ lớp cho “Hệ thống bán hàng trên mạng”
6.8 Chọn từ danh sách dưới đây những thuật ngữ thích hợp để điền vào các chỗ [(…)] trong đoạn văn mô tả về công việc trong phân tích và thiết kế hệ thống
Trong giai đoạn phân tích, chúng ta khảo sát hệ thống để trả lời câu hỏi [(1)] và nghiên cứu các [(2)], đồng thời xem xét sự tương tác giữa các lớp đối tượng thông qua biểu đồ trình tự và biểu đồ trạng thái Nhiệm vụ chính của giai đoạn thiết kế là chuyển từ câu hỏi [(1)] sang câu hỏi [(3)] Do đó, thiết kế hướng đối tượng tập trung vào việc xây dựng các [(4)] của các đối tượng, nhằm đảm bảo hệ thống thực hiện được các yêu cầu đã được xác định trong pha phân tích.
Chọn câu trả lời: a “như thế nào?” b biểu đồ cộng tác c những cài gì d mối quan hệ
KIẾN TRÚC HỆ THỐNG VÀ PHÁT SINH MÃ TRÌNH
Kiến trúc của Hệ thống
Mục đích của thiết kế là cung cấp giải pháp logic cho bài toán ứng dụng và mô tả cách hệ thống thực thi các nhiệm vụ đã được phân tích, giúp chuyển đổi yêu cầu thành sản phẩm thực tế.
Xây dựng các thiết kế chi tiết cho các thành phần của hệ thống ở mức cao nhằm phục vụ cho việc cài đặt ở giai đoạn sau Đồng thời, kiến trúc của hệ thống cần được xác định rõ ràng để đảm bảo tính linh hoạt, khả năng mở rộng, dễ bảo trì và thân thiện với người sử dụng.
Kiến trúc hệ thống là cấu trúc tổ chức của một hệ thống, bao gồm nhiều bộ phận tương tác qua các giao diện và mối quan hệ kết nối Những thành phần này hoạt động ở nhiều mức khác nhau và được kết hợp thành một thể thống nhất thông qua các ràng buộc.
Kiến trúc phần mềm mô tả cấu trúc của các hệ thống con và thành phần, cùng với mối quan hệ giữa chúng Các thành phần này được phân tích từ nhiều góc độ để làm nổi bật các thuộc tính chức năng và phi chức năng của hệ thống phần mềm.
Kiến trúc hệ thống được chia thành hai loại: logic và vật lý
Kiến trúc logic xác định các lớp, đối tượng, quan hệ và sự cộng tác cần thiết để tạo ra chức năng của hệ thống Nó được thể hiện thông qua các biểu đồ ca sử dụng, biểu đồ lớp và biểu đồ tương tác Kiến trúc ba tầng hiện nay, bao gồm tầng giao diện, tầng tác nghiệp và tầng lưu trữ, là một trong những kiến trúc phổ biến nhất.
Kiến trúc vật lý mô tả chi tiết hệ thống từ góc độ phần cứng và phần mềm, đồng thời thể hiện cấu trúc vật lý và sự phụ thuộc giữa các mô đun trong việc triển khai các khái niệm đã được định nghĩa trong kiến trúc logic Nó liên quan chặt chẽ đến cài đặt và được mô hình hóa thông qua biểu đồ thành phần và biểu đồ triển khai Biểu đồ thành phần bao gồm các đơn vị mã chương trình và cấu trúc tệp, trong khi biểu đồ triển khai thể hiện kiến trúc hệ thống khi thực thi, bao gồm các thiết bị vật lý và phần mềm được cài đặt trên đó.
Như ở phần phân tích đã nêu: Kiến trúc phổ biến cho các hệ thống phần mềm hiện nay là kiến trúc ba tầng
1 Tầng trình diễn: biểu diễn và giới thiệu các thành phần của hệ thống thông qua các giao diện đồ hoạ, các Window, các hộp thoại, v.v Các thực thể trong hệ thống được thể hiện sao cho vừa thân thiện với người sử dụng, vừa phù hợp với bài toán ứng dụng Ví dụ, cửa sổ “Bán hàng” của hệ thống bán hàng được thiết kế ở tầng trình diễn như ở hình 6-9 thể hiện giao diện giữa người bán và hệ thống
2 Tầng logic ứng dụng: mô tả các đối tượng thực thi các nhiệm vụ và các qui luật điều hành các tiến trình của hệ thống Hệ thống phần mềm có hai loại đối tượng cơ bản:
2.1 Những đối tượng nghiệp vụ: là những đối tượng đại biểu cho các khái niệm của miền ứng dụng Ví dụ, trong hệ thống bán hàng, các đối tượng :PhienBanHang, :ThanhToan, v.v là những đối tượng thực hiện các nhiệm vụ của bài toán ứng dụng
2.2 Những đối tượng dịch vụ (Service Object): những đối tượng không nằm trong phạm vi bài toán nhưng cung cấp các dịch vụ cho hệ thống như: làm môi giới, tương tác với CSDL, trao đổi thông tin, lập báo cáo, đảm bảo án toán, an ninh dữ liệu, v.v
Tầng hai được thể hiện ở các biểu đồ: lớp, trạng thái, cộng tác, hành động và biểu đồ triển khai
3 Tầng lưu trữ (Storage): thể hiện cơ chế lưu trữ đảm bảo nhất quán và bền vững dữ liệu Hiện nay có hai mô hình CSDL chính đang được sử dụng phổ biến là: mô hình dữ liệu quan hệ và mô hình dữ liệu hướng đối tượng Để lưu trữ dữ liệu cho hệ thống, ta phải lựa chọn hệ quản trị CSDL và những phương pháp biến đổi dữ liệu, biến đổi các câu truy vấn cho phù hợp với công nghệ hiện đại và với phạm vi ứng dụng Kiến trúc sư đối tượng phải lựa chọn công nghệ CSDL thích hợp để phát triển hệ thống Khi phân tích, thiết kế hướng đối tượng và nếu lựa chọn mô hình dữ liệu quan hệ thì người phát triển hệ thống phải quan tâm đến những vấn đề về tích hợp dữ liệu để đảm cho phép người sử dụng truy cập được tới tất cả các dữ liệu từ nhiều mô hình khác nhau một cách trong suốt
Quá trình phát triển phần mềm tương tự như quá trình học hỏi và nhận thức của con người, diễn ra theo cách lặp lại và tích lũy để đạt được sự hoàn thiện liên tục Do đó, kiến trúc hệ thống cần được thiết kế phù hợp với sự phát triển và khả năng mở rộng của nó.
Trong triển khai cài đặt, kiến trúc ba tầng thường được tổ chức theo nhiều phương án khác nhau Có thể thực hiện:
1 Cả 3 tầng trên cùng máy (hệ thống nhỏ)
2 Tầng trình diễn và tầng logic ứng dụng trên máy khách (Client Computer), tầng lưu trữ trên Sever (hệ thống loại vừa)
3 Tầng trình diễn trên máy người sử dụng, tầng logic ứng dụng trên máy trạm phục vụ ứng dụng (Application Server), còn tầng lưu trữ tổ chức ở trạm phục vụ dữ liệu (Data Server) (những hệ thống lớn)
Hiện nay, các ngôn ngữ lập trình hướng đối tượng như Java cùng với các công nghệ cơ sở dữ liệu hướng đối tượng đã hỗ trợ hiệu quả cho việc cài đặt phân tán Để thiết kế một hệ thống, cần chia nó thành các hệ thống con gọi là các gói (packages), trong đó các gói có mức độ phụ thuộc lẫn nhau Do đó, một kiến trúc chi tiết chung cho hệ thống cần được xây dựng để biểu diễn rõ ràng các mối quan hệ phụ thuộc này.
Hình 7-1 Kiến trúc chung của hệ thống
CSDL quan hệ Trao đổi tin Giao diện với
Các khung ứng dụng & sự hỗ trợ của các hệ thống thư viện
Một số điểm cần lưu ý trong kiến trúc nêu trên
1 Các gói giao diện CSDL quan hệ và CSDL đối tượng cung cấp các cơ chế nhất quán để trao đổi với các CSDL khác
2 Các gói dịch vụ hướng đối tượng ở mức cao như: lập báo cáo, giao diện với CSDL, đảm bảo an ninh, trao đổi (truyền thông), v.v được phát triển theo kỹ nghệ hướng đối tượng và thường được các nhà phát triển phần mềm hệ thống cung cấp
Biểu đồ thành phần
Biểu đồ thành phần (Component Diagram) là một công cụ quan trọng trong việc mô tả các thành phần của hệ thống và mối quan hệ phụ thuộc giữa chúng Các thành phần này có thể bao gồm các module, thư viện, hoặc dịch vụ, giúp hình dung cấu trúc tổng thể của hệ thống một cách rõ ràng và dễ hiểu.
Thành phần mã nguồn, có ý nghĩa vào thời điểm dịch chương trình Thông thường nó là tập các chương trình cài đặt các lớp Ví dụ, trong C++, mỗi tệp
Trong lập trình, các tệp cpp và h đóng vai trò quan trọng trong việc tổ chức mã nguồn Mỗi lớp thường được ánh xạ vào hai tệp tương ứng, với tệp h chứa định nghĩa và tệp cpp chứa triển khai Trước khi phát sinh mã chương trình, việc ánh xạ này cần được thực hiện để đảm bảo tính nhất quán và rõ ràng trong cấu trúc mã.
Thành phần mã nhị phân là mã trình nhị phân được dịch 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) Các thành phần 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 là tệp chương trình có thể thực thi được (các tệp exe)
Nó là kết quả của chương trình liên kết các thành phần nhị phân
Biểu đồ thành phần giúp người phát triển hệ thống xác định các thư viện mã trình có sẵn và các tệp thực thi (.exe) khi tiến hành dịch và liên kết thành công.
Trong các thành phần, chỉ có một loại quan hệ phụ thuộc được thể hiện qua đường mũi tên đứt nét Kết nối phụ thuộc chỉ ra rằng thành phần phụ thuộc cần phải được dịch sau thành phần chính Cần lưu ý rằng nên tránh tạo ra các phụ thuộc vòng tròn trong biểu đồ thành phần.
Ví dụ: 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
Trong UML (Unified Modeling Language) và Rose, có nhiều biểu tượng đại diện cho các thành phần, thể hiện sự phụ thuộc giữa chúng trong biểu đồ thành phần.
Thành phần: biểu tượng thành phần (hình 7-3a) đượ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 (AciveX, Applet, DLL, exe, v.v.)
Chương trình MyProgram (System.exe) bao gồm các đặc tả cho chương trình con, được minh họa qua biểu tượng thành phần trong hình 7-3b và đặc tả dạng cài đặt trong hình 7-3c Đáng chú ý, chương trình con này không bao gồm 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, như tệp chứa hàm main() trong C/C++ Đặc tả gói là tệp header chứa thông tin về các hàm thành phần của lớp, ví dụ tệp h định nghĩa các hàm prototype trong C/C++ Biểu tượng cho thân gói bao gồm mã lệnh của các hàm thành phần, thường là tệp cpp trong C/C++ Các biểu tượng khác đại diện cho phần đặc tả và nội dung của những nhiệm vụ độc lập.
Hình 7-3 Các thành phần của hệ thố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ột mẫu rập khuôn được sử dụng để phân nhóm các thành phần trong lập trình, bao gồm nhiều lựa chọn như: , đặ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, và ứng dụng.
+ 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, điều này giúp Rose xác định tệp mà mã chương trình của lớp sẽ được ghi vào 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 tiêu 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ủa hệ thống.
Biểu đồ triển khai
Biểu đồ triển khai (Deployment Diagram) thể hiện cấu hình các phần tử xử lý trong quá trình chạy chương trình, bao gồm các nút mạng và tiến trình phần mềm hoạt động trên các phần tử đó Nó mô tả mối quan hệ giữa phần cứng và phần mềm trong hệ thống, đồng thời chỉ ra toàn bộ các nút trên mạng, kết nối giữa chúng và các tiến trình đang chạy Ví dụ, biểu đồ triển khai của hệ thống có thể được tổ chức như hình 7-4.
Hình 7-4 Biểu đồ triển khai của hệ thống
Mỗi nút trong mạng là một đối tượng vật lý như máy tính, máy in, hoặc thiết bị truyền tin, sở hữu tài nguyên tính toán riêng Các nút này được kết nối với nhau thông qua các giao thức như TCP/IP, cho phép chúng giao tiếp và trao đổi dữ liệu hiệu quả.
Các phần tử (nút) của biểu đồ triển khai
B ộ x ử lý (Processor): bộ xử lý của máy tính, máy chủ, trạm làm việc, v.v
Các bộ xử lý được đặc tả chi tiết bằng cách bổ sung thêm các thông tin:
+ Stereotype: để phân nhóm các bộ xử lý
+ Đặc tính: mô tả các tính chất vật lý của mỗi bộ xử lý như: tốc độ tính toán, dung lượng bộ nhớ, v.v
+ Lịch biểu (Schelduling): mô tả loại lịch biểu thời gian xử lý, bao gồm:
- Preemptive cho phép những tiến trình có mức ưu tiên cao hơn có thể chiếm quyền xử lý đối với những tiến trình có mức ưu tiên thấp hơn
- Non Preemptive không có ưu tiên, một tiến trình chỉ dừng khi nó tự kết thúc
- Cyclic chỉ ra chu kỳ điều khiển giữa các tiến trình
- Executive: các lịch biểu được điều khiển bằng thuật toán, bằng chương trình
- Manual: tiến trình được điều khiển bằng người sử dụng
Thiết bị là các máy móc hoặc phần cứng không bao gồm bộ xử lý trung tâm, ví dụ như màn hình, máy in và máy vẽ Ngoài ra, thiết bị còn có thể cung cấp thông tin chi tiết về Stereotype và một số tính chất vật lý khác.
Tiến trình là luồng thực hiện của một chương trình trong bộ xử lý Mỗi chương trình khi được thực thi sẽ được coi là một tiến trình Các tiến trình thường được gán mức ưu tiên, và bộ xử lý sẽ ưu tiên thực hiện những tiến trình có mức độ ưu tiên cao hơn.
Ánh xạ các thiết kế sang mã chương trình
Chúng ta sẽ không đi sâu vào lập trình hướng đối tượng, mà tập trung vào việc giới thiệu các phương pháp ánh xạ kết quả thiết kế thành mã chương trình.
Hiện nay nhiều công cụ phát triển hiện đại cung cấp những môi trường tiện lợi để nhanh chóng chuyển đổi giữa thiết kế và mã hoá chương trình
Cài đặt bằng một ngôn ngữ lập trình hướng đối tượng đòi hỏi phải viết mã nguồn cho:
Các phần định nghĩa lớp,
Các định nghĩa hàm thành phần
Trong các phần sau chúng ta thảo luận về phần sinh mã trong C++ cho những thiết kế nêu trên
7.4.1 Tạo lập các định nghĩa lớp từ những thiết kế biểu đồ lớp
Trong quá trình thiết kế, biểu đồ lớp được xây dựng một cách chi tiết để mô tả tên lớp, các thuộc tính, hàm thành phần và mối quan hệ giữa các đối tượng trong hệ thống Những thông tin này cung cấp đủ dữ liệu để tạo ra các định nghĩa lớp trong ngôn ngữ lập trình hướng đối tượng như C++ Định nghĩa lớp bao gồm các hàm và thuộc tính đơn giản, giúp phát triển ứng dụng hiệu quả hơn.
Từ các lớp đã được thiết kế chi tiết, thực hiện ánh xạ như sau:
- Các thuộc tính đơn được chuyển tương ứng sang các biến có kiểu dữ liệu phù hợp,
- Các hàm được chuyển sang các hàm prototype
Ví dụ, định nghĩa lớp DongBanHang trong C++ như sau:
Hình 7-5 Định nghĩa lớp dựa vào biểu đồ lớp
DongBanHang soLuong: int subtotal(): Number
MoTaMatHang upc: UPC giaBan: Number moTa: Text class DongBanHang{
DongBanHang(MoTaMatHang mTa, int soLuong); public float subtotal(); private int soLuong;
Lưu ý: khi định nghĩa, chúng ta thường phải bổ sung thêm hàm tạo lập
Constructor được sử dụng để tạo ra các đối tượng trong chương trình, như được thể hiện trong biểu đồ cộng tác hình 6.20 Cụ thể, đối tượng DongBanHang nhận thông điệp create(mt, n) để tạo ra dòng bán hàng với mô tả mt và số lượng n Trong C++, toán tử tạo lập là hàm có cùng tên với tên lớp, giúp hỗ trợ quá trình này.
Dữ liệu kết quả của hàm subtotal() đã bị thay đổi từ kiểu Number sang kiểu float, cho thấy rằng người lập trình có thể linh hoạt chọn kiểu dữ liệu phù hợp cho các biến thuộc tính và hàm, mà không nhất thiết phải tuân theo bản thiết kế ban đầu.
Bổ sung thêm các thuộc tính tham chiều
Thuộc tính tham chiếu là thuộc tính được sử dụng để tham chiếu đến đối tượng phức hợp khác, không phải là những kiểu dữ liệu nguyên thuỷ
Thuộc tính tham chiếu của một lớp được xác định bởi những quan hệ kết hợp và sự điều khiển trong thiết kế biểu đồ lớp
Trong biểu đồ lớp của hệ thống bán hàng, lớp DongBanHang có mối quan hệ kết hợp với MoTaMatHang, với mũi tên điều khiển chỉ hướng gửi thông điệp trong quá trình trao đổi thông tin Điều này trong C++ yêu cầu lớp DongBanHang phải khai báo biến tham chiếu tới MoTaMatHang.
Thuộc tính tham chiếu thường không rõ ràng và được suy ra từ các mối quan hệ trong biểu đồ lớp Khi vai trò của đầu quan hệ có mặt trong biểu đồ, chúng ta có thể sử dụng nó làm tên thuộc tính tham chiếu Do đó, định nghĩa của lớp DongBanHang được hoàn thiện như hình 7-6.
Hình 7-6 Bổ sung thêm thuộc tính tham chiếu vào lớp
Tên của vai trò được sử dụng trong tên của thuộc tính class DongBanHang{
DongBanHang(MoTaMatHang mTa, int soLuong); public float subtotal(); private int soLuong; private MoTaMatHang moTa;
DongBanHang soLuong: int subtotal(): Number
MoTaMatHang upc: UPC giaBan: Number moTa: Text moTa biến đơn biến tham chiếu
Tương tự như trên, chúng ta có thể định nghĩa các lớp khác, ví dụ lớp HBH được định nghĩa như hình 7-7
Hình 7-7 Định nghĩa lớp HBH
7.4.2 Định nghĩa hàm từ biểu đồ cộng tác
Biểu đồ cộng tác minh họa cách thức gửi thông điệp đến các đối tượng thông qua các lời gọi hàm Dãy thông điệp nhận được sẽ được chuyển đổi tương ứng thành các lệnh trong định nghĩa hàm thành phần của lớp.
Chúng ta hãy xét biểu đồ cộng tác mô tả nhiệm vụ enterItems (nhập dữ liệu vào) và dựa vào đó để định nghĩa hàm enterItems()
Hình 7-8 Biểu đồ cộng tác cho enterItems
Thông điệp enterItems được gửi cho một đối tượng của HBH, do vậy, trong lớp HBH sẽ có hàm enterItems() được định nghĩa như sau:
HBH endSale() enterItems() makePayment(soTien: Number)
PhienBanHang ngayBan: Date gioBan: Time isComplete: Boolean becomeComplete() makeLineItem() total() muc public class HBH{
HBH(DanhMucMatHang pc); public void endSale(); public void enterItems(); public void makePayment(float soTien); private PhienBanHang banHang ; private DanhMucMatHang muc;
3.1: create(mt,n) public void enterItems(UPC upc, int soLuong);
Để thực hiện nhiệm vụ enterItems(), trước tiên cần tạo ra một đối tượng PhienBanHang mới nếu đây là mặt hàng đầu tiên được nhập vào Điều này được thể hiện qua câu lệnh if (isNewSale()){banHang = new PhienBanHang();}.
Hàm isNewSale() là một hàm private dùng để kiểm tra trạng thái của đối tượng PhienBanHang Hàm này xác định xem đối tượng có rỗng hay không, tức là liệu PhienBanHang đã được thiết lập hay phiên bán hàng trước đó đã kết thúc Cụ thể, hàm trả về giá trị true nếu biến banHang là null.
C++ không có kiểu dữ liệu Boolean, nhưng nó coi giá trị của biểu thức khác 0 là đúng (true) và bằng 0 là sai (false) Hàm này được thêm vào lớp HBH bên cạnh các hàm đã được xác định như trong hình 7.7.
Thông điệp 2: Tiếp theo, một thông điệp được gửi cho :DanhMucMatHang để xác định các thông tin về mặt hàng có mã là upc
DanhMucMatHang moTa = muc.specification(upc); muc là một đối tượng của DanhMucMatHang
Thông điệp 3: Thông điệp thứ ba makeLineItem được gửi cho :PhienBanHang để xác lập một dòng bán hàng thông qua đối tượng banHang banHang.makeLineItem(moTa, soLuong);
Mỗi thông điệp trong biểu đồ cộng tác được gửi đi nhằm thực hiện yêu cầu của thông điệp đầu tiên sẽ được ánh xạ thành một chuỗi các câu lệnh tương ứng trong định nghĩa hàm thành phần.
Theo nguyên tắc đó, hàm enterItems() được định nghĩa đầy đủ như sau: public void enterItems(UPC upc, int soLuong){ if (isNewSale()){banHang = new PhienBanHang();}
DanhMucMatHang moTa = muc.specification(upc); banHang.makeLineItem(moTa, soLuong);
} Đị nh ngh ĩ a hàm makeLineItem()
Xét tiếp biểu đồ cộng tác cho enterItems(upc, soLuong) ở hình 6-20, lớp
PhienBanHang nhận thông điệp makeLineItem(moTa, soLuong) để thực hiện yêu cầu này, cần gửi hai thông điệp: create(moTa, soLuong) cho sl: DongBanHang và adds(sl) cho tập các đối tượng DongBanHang Hàm makeLineItem() trong lớp PhienBanHang được định nghĩa như sau: public void makeLineItem(MoTaMatHang moTa, int soLuong) { lineItem.addElement(new DongBanHang(moTa, soLuong); }.
Thứ tự cài đặt các lớp
Các lớp nên được cài đặt từ những lớp cặp bộ yếu dần đến những lớp cặp bộ cao hơn Ví dụ, các lớp đầu tiên có thể được lựa chọn để cài đặt trong hệ HBH.
ThanhToan, hoặc MoTaMatHang, sau đó là DanhMucMatHang, PhienBanHang, rồi đến HBH và CuaHang, v.v như hình 7-9
Hình 7-9 Thứ tự cài đặt các lớp
Danh sách một số lớp được định nghĩa trong C++
1 Lớp ThanhToan class ThanhToan{ private: float tongSoTien; public:
ThanhToan(float soTien){ tongSoTien = soTien;
Chứa 1 MoTaMatHang maSanPham: UPC giaBan: Number moTa: Text
PhienBanHang ngayBan: Date gioBan: Time becomeComplete() makeLineItem() makePayment() total()
CuaHang diaChi: Address tenGoi: String addSale()
Có Được-mô-tả-bởi
7 public class MoTaMatHang{ private: int upc = 0; float giaBan = 0.0;
MoTaMatHang(int ma, float p, String mt){ upc = ma; giaBan = p; strcpy(moTa, mt);
MoTaMatHang(int ma, float p, String mt){ upc = 0; giaBan = 0; strcpy(moTa, "");
} int getUPC(){return upc;} float getPrice(){return giaBan;}
#define N 100 public class DanhMucMatHang{ private:
DanhMucMatHang(){ for(inh k = 0; k < N; k++) danhSachMH[k] = new MoTaMatHang();
MoTaMatHang find(int upc){ for(k = 0; k < N; k++) if (danhSachMH[k].getUPC() == upc) return danhSachMH[k]; }
4 Lớp DongBanHang class DongBanHang{ private: int soLuong;
DongBanHang(MoTaMatHang mt, int n){ moTa = mt; soLuong = n;
} float subtotal(){ return soLuong * moTa.getPrice();
Date ngayBan; // Kiểu ngày/tháng/năm
Time gioBan; // Kiểu giờ/phút/giây int soDong = 0; int isComplete = 0; // false
ThanhToan traTien; public: getBalance(){ return traTien.getAmount() - total();
} void becomeComplete(){isComplete = 1;} int isComplete() {return isComplete;} void makeLineItem(MoTaMatHang mt, int sl){ lineItem[soDong++]= new DongBanHang(mt, sl);
} float total(){ float t = 0.; for (int k = 0; k < soDong; k++) t += lineItem[k].subtotal(); return t;
} void makePayment(float soTien){ traTien = new ThanhToan(soTien);
6 Lớp HBH class HBH{ private:
HBH(DanhMucMatHang danhMuc){ catalog = danhMuc;} void endSale(){ banHang.becomeComplete();} void enterItems(int upc, int soLuong){ if (isNewSale(){ banHang = new PhienBanHang();
MoTaMatHang mt = catalog.find(upc); banHang.makeLineItem(mt, soLuong);
} void makePayment(soTien){ banHang.makePayment(soTien);
} int isNewSale(){ return (banHang == null) || (banHang.isComplete());
7 Lớp CuaHang class CuaHang{ private:
HBH post = new HBH(dm); public:
Tương tự, dễ dàng định nghĩa cho tất cả các lớp khác của hệ thống HBH.
Thực hành trên Rose
7.6.1 Xây dựng biểu đồ thành phần
+ Tạo lập mới hoặc mở một biểu đồ thành phần đã được tạo lập trước,
+ Bổ sung, loại bỏ các thành phần,
+ Đặc tả chi tiết các thành phần: gán Stereotype, chọn ngôn ngữ Language, chọn lớp để gán Assign,
+ Thiết lập các mối quan hệ phụ thuộc giữa các thành phần
7.6.2 Xây dựng biểu đồ triển khai
+ Tạo lập mới hoặc mở một biểu đồ triển khai đã được tạo lập trước,
+ Bổ sung, loại bỏ các nút, các phần tử xử lý Processor,
+ Đặc tả chi tiết các phần tử xử lý: gán Stereotype, bổ sung một số đặc tính như
Preemtive, Non preemtive, Cyclic, v.v và gán Schelduling,
+ Bổ sung các thiết bị Device và đặc tả chúng,
+ Thiết lập các mối quan hệ kết nối giữa các nút,
+ Bổ sung và huỷ bỏ các tiến trình Process
7.6.3 Phát sinh mã trình bằng Rose
Có sáu bước cơ bản thực hiện để phát sinh mã chương trình:
1 Thiết lập các thuộc tính của mô hình
3 Tạo lập các thành phần
4 Gán các lớp vào thành phần
5 Chọn lớp, thành phần hay gói để phát sinh mã
6 Phát sinh mã chương trình
Không phải tất cả các ngôn ngữ lập trình đều cần tuân thủ đầy đủ sáu bước trong quy trình phát triển Ví dụ, khi viết mã chương trình bằng C++ hoặc Java cho các lớp đã được thiết kế chi tiết, bạn chỉ cần thực hiện các bước 5 và 6, và bước 1 không bắt buộc Tuy nhiên, từ góc độ quy trình công nghiệp, việc thực hiện cả sáu bước vẫn là điều nên làm để đảm bảo chất lượng và tính hiệu quả.
Bước 1: Thiết lập các đặc tính của mô hình
Có nhiều đặc tính được sử dụng để phát sinh mã nguồn có thể gán cho lớp, vai trò
(Role), thuộc tính, hàm và các thành phần khác của lớp
Lớp trong lập trình có các đặc tính quan trọng như các toán tử tạo lập và huỷ tử, toán tử tạo lập nhân bản, phép đối sánh, cùng với các phương thức truy cập dữ liệu (get/set methods) Những yếu tố này giúp xác định cách thức hoạt động và quản lý dữ liệu trong lớp, từ đó nâng cao khả năng tái sử dụng và bảo trì mã nguồn.
+ Các đặc tính của vai trò bao gồm: thiết lập các phương thức truy cập, lớp chứa
+ Các đặc tính của phương thức bao gồm: những phép toán chung như phương thức abstract, virtual, static, friend, v.v
Các đặc tính trong mô hình điều khiển việc tự động phát sinh mã chương trình, như đặc tính GenrateGetOperation trong C++, cho phép tạo ra các hàm với tiền tố getX để truy cập dữ liệu private trong lớp Trước khi phát sinh mã, cần xem xét và có thể điều chỉnh các đặc tính của mô hình Để kiểm tra các đặc tính này, người dùng có thể truy cập Tools > Options hoặc nhấn đúp vào Model Properties từ Browser, sau đó chọn ngôn ngữ lập trình, ví dụ C++.
Bạn có thể dễ dàng thay đổi giá trị và nguồn của các đặc tính bằng cách nhấn chuột vào đặc tính cần chỉnh sửa và chọn các đại lượng phù hợp từ menu thả xuống.
Tạo lập tập đặc tính tạm thời trong C++ giúp bạn tùy chỉnh và sử dụng các đặc tính không mặc định Để thực hiện điều này, bạn có thể lựa chọn các phương pháp phù hợp để xây dựng tập đặc tính tạm thời cho chương trình của mình.
To edit a property set in C++, navigate to Tools > Model Properties > Edit > C++ tab, then select Edit Set Afterward, click the Close button in the Clone the Property Set window and enter a new name for the property set If the temporary property set is no longer needed, you can choose Remove to delete it.
Hình 7-10 Các đặc tính của mô hình để sinh mã cho lớp trong C++
Bước 2: Kiểm tra mô hình
Chức năng Check Model trong Tools giúp kiểm tra sự nhất quán giữa các đơn thể khi mô hình được lưu trữ trong nhiều đơn vị điều khiển Chức năng này phát hiện sai phạm, điểm không thống nhất và lỗi trong mô hình Sau khi chọn Tools > Check Model, các lỗi sẽ được hiển thị trong cửa sổ Log Một lỗi phổ biến là các thông điệp trong biểu đồ tương tác không được ánh xạ đúng vào các phương thức của lớp tương ứng Mục Access Violation sẽ xác định các vi phạm liên quan đến quan hệ giữa hai lớp ở hai gói khác nhau mà không có sự liên kết giữa chúng Để xem các vi phạm này, hãy chọn Report > Show Access Violation.
Bước 3: Tạo lập thành phần hay mở biểu đồ thành phần
Chúng ta có thể tạo mã cho từng lớp hoặc cho các thành phần chứa một số lớp nhất định và các mẫu rập khuôn (stereotype) Để ánh xạ các lớp trong mô hình sang ngôn ngữ lập trình và các đơn thể phần mềm đã xác định, cần có các thành phần thiết yếu Các loại thành phần bao gồm mã nguồn, tệp thực thi (.exe), tệp thư viện, và nhiều hơn nữa Các lớp và giao diện cần được gán vào một thành phần của một ngữ cài đặt hoặc vào các thành phần của cùng một ngôn ngữ.
3.1 Tạo lập thành phần mới
1 Chọn Component view ở vùng Browser (thường hiển thị ở bên trái nhất)
2 Nhấn chuột phải để hiển thị thực đơn tắt (shortcut) Chọn New > Package hoặc New > Component rồi đặt tên cho chúng, nếu không chúng sẽ được đặt tên mặc định Bạn chọn package nếu muốn tạo lập một gói mới chứa một số lớp để phát sinh mã chương trình
3 Hoặc nhấn chuột phải để mở thực đơn tắt và nhấn đúp chuột để mở Open
Specification Trong đó bạn có thể chọn mẫu rập khuôn cho thành phần trong Stereotype và gán ngôn ngữ cho thành phần ở hộp Language (xem hình 7-11)
Hình 7-11 Tạo lập thành phần mới
Lưu ý: để tạo ra header file thì chọn Package Specification, còn nếu muốn tạo ra tệp nội dung thì chọn Package Body ở Stereotype
3.2 Mở biểu đồ và tạo lập các thành phần Để tạo lập các thành phần trong biểu đồ thành phần chúng ta làm như sau:
2 Sử dụng biểu tượng Component trong thanh công cụ để bổ sung những loại thành phần mới vào biểu đồ
Bước 4: Gán lớp, giao diện vào cho thành phần
Mỗi thành phần mã nguồn trong C++ biểu diễn tệp mã nguồn của một hoặc nhiều lớp, với mỗi lớp được phân chia thành hai tệp: tệp header (.h) và tệp chứa thân lớp (.cpp) Tuy nhiên, trong trường hợp sử dụng Rose, quá trình này có thể được rút gọn, cho phép mã chương trình cho một lớp được gán trực tiếp vào thành phần lựa chọn mà không cần qua bước tách biệt.
Một lớp hoặc giao diện có thể được gán cho các thành phần trong ngôn ngữ lập trình, hoặc có thể gán cho một số thành phần khác nhau trong cùng một ngôn ngữ.
1 Chọn lớp ở Browser, hoặc ở biểu đồ, và mở Open Specification của lớp đó
2 Ở mục Components tab, chọn Show All Components
3 Nhấn chuột phải ở thành phần tương ứng và kích vào Assign để gán lớp đã chọn vào thành phần đó
Bạn có thể chọn thành phần trong Browser và kéo nó đến lớp tương ứng trên biểu đồ, hoặc mở tab Components trong phần đặc tả lớp Sau khi gán lớp cho thành phần, tên lớp sẽ hiển thị trong ngoặc đơn bên cạnh tên thành phần trong Browser Để gán nhiều lớp (giao diện) cho một thành phần, bạn cần thực hiện các bước tương tự.
1 Chọn thành phần ở Browser, hoặc ở biểu đồ thành phần, và mở Open Specification của thành phần đó
2 Về Realizes tab, kích vào mục Show All Classes
3 Đối với những lớp cần gán vào thành phần này thì nhấn chuột phải vào lớp đó và kich vào Assign để gán nó vào thành phần đã chọn
4 Về mục General tab, có thể đặt tên mới cho thành phần ở hộp Name, chọn kiểu cho thành phần đó ở hộp Stereotype, và gán ngôn ngữ cài đặt cho thành phần này ở hộp Language
Bạn có thể chọn từng lớp giao diện và di chuột để gán các lớp đã chọn cho thành phần tương ứng trong biểu đồ hoặc trên trình duyệt Để gán một ngôn ngữ cho một lớp, bạn thực hiện tương tự đối với các thành phần.
1 Mở phần đặc tả Open Specification của lớp (nhấn chuột phải ở tên lớp)
2 Về mục Components tab, kích vào mục Show All Components Ở trường
Language hiển thị ngôn ngữ đã được gán cho thành phần
3 Nhấn chuột phải ở thành phần mà bạn định gán lớp vào và nhấn Assign Để tìm xem ngôn ngữ nào được gán cho một lớp ta thực hiện như sau:
1 Mở phần đặc tả Open Specification của lớp (nhấn chuột phải ở tên lớp)
2 Bạn sẽ nhìn thấy ngôn ngữ lập trình đã được gán cho lớp đó ở trường
Language khi chọn mục Component (xem hình 7-11)
Bước 5: Chọn lớp, thành phần hay gói