(NB) Căn cứ vào chương trình đào tạo nghề Thiết kế trang web, giáo trình giúp cung cấp cho người học những kiến thức cơ bản về phân tích thiết kế hệ thống cũng như kỹ năng sử dụng phần mềm Rose để thiết kế hướng đối tượng. Cấu trúc chung của giáo trình này bao gồm 9 chương, phần 1 giáo trình sẽ bao gồm những kiến thức cơ bản về: Khái quát về UML, mô hình hóa trường hợp sử dụng, mô hình hóa tương tác đối tượng, biểu đồ lớp và gói.
KHÁI QUÁT VỀ UML
GIỚI THIỆU UML
UML là ngôn ngữ chuẩn để lập kế hoạch chi tiết cho phần mềm, phù hợp với việc mô hình hóa các hệ thống như hệ thông tin doanh nghiệp, ứng dụng phân tán trên Web và hệ thống nhúng thời gian thực Ngôn ngữ này dễ hiểu và dễ sử dụng, cho phép quan sát từ góc độ phát triển và triển khai hệ thống UML không chỉ được con người mà còn được máy móc sử dụng, giúp cấu trúc rõ ràng suy nghĩ và hành động Phương pháp này hướng dẫn người dùng về cách thực hiện công việc, thời điểm thực hiện và lý do thực hiện, đồng thời chứa các mô hình để mô tả các khía cạnh khác nhau của hệ thống.
Phương pháp và ngôn ngữ mô hình hóa khác nhau chủ yếu ở chỗ ngôn ngữ mô hình hóa không cung cấp tiến trình rõ ràng về việc thực hiện các tác vụ, bao gồm những gì, cách thức, thời điểm và lý do thực hiện Giống như các ngôn ngữ mô hình hóa khác, UML có ký pháp riêng với các biểu tượng được sử dụng trong mô hình và một bộ luật quy định cách sử dụng chúng Các luật này bao gồm cú pháp, ngữ nghĩa và quy tắc thực tiễn để tạo ra câu có nghĩa.
Mặc dù nắm vững ngôn ngữ UML là quan trọng, nhưng điều này không đảm bảo rằng mô hình sẽ đạt chất lượng cao Giống như một nhà văn viết tiểu thuyết bằng ngôn ngữ tự nhiên, ngôn ngữ chỉ là công cụ, và sự thành công của tác phẩm phụ thuộc hoàn toàn vào khả năng của nhà văn Để tận dụng UML một cách hiệu quả, cần phải hiểu ba vấn đề chính, bao gồm các phần tử cơ bản của mô hình UML.
Các qui định liên kết các phần tử mô hình
Một số cơ chế chung áp dụng cho ngôn ngữ này
UML là một ngôn ngữ quan trọng trong phát triển phần mềm, nhưng nó không phải là một quy trình độc lập UML rất thích hợp với các quy trình phát triển dựa trên trường hợp sử dụng (Use case - UC), tập trung vào kiến trúc và hỗ trợ tương tác gia tăng.
Ngôn ngữ giao tiếp cần có từ vựng và quy tắc tổ hợp từ để truyền đạt ý nghĩa Ngôn ngữ mô hình, như UML, cung cấp từ vựng và quy tắc để biểu diễn các khía cạnh vật lý và khái niệm của hệ thống, đóng vai trò quan trọng trong lập kế hoạch chi tiết phần mềm Không có một mô hình nào có thể đáp ứng toàn bộ hệ thống, vì vậy cần xây dựng nhiều mô hình khác nhau để thể hiện các khung nhìn đa dạng của kiến trúc hệ thống trong quá trình phát triển phần mềm Mặc dù UML hướng dẫn cách xây dựng và đọc mô hình, nhưng không chỉ định mô hình nào cần thiết và thời điểm lập chúng Quy trình phát triển phần mềm sẽ xác định các sản phẩm cần thiết, hoạt động và nhân sự liên quan, đồng thời quản lý cách thức sử dụng chúng trong toàn bộ dự án.
2.1.1.2 - UML là ngôn ngữ để hiển thị
Với nhiều lập trình viên, không có khoảng cách từ ý tưởng đến cài đặt mã trình
Việc viết mã trình cho các vấn đề phần mềm có thể được thực hiện ngay lập tức, nhưng giao tiếp giữa mô hình khái niệm và các yếu tố khác trong vòng đời phát triển phần mềm sẽ gặp khó khăn nếu không có ngôn ngữ chung Khi một dự án sử dụng ngôn ngữ riêng, người mới sẽ gặp nhiều trở ngại Một số vấn đề phần mềm có thể được làm rõ hơn thông qua mô hình thay vì chỉ dựa vào mã lập trình Ví dụ, ý nghĩa của phân cấp lớp có thể được suy luận nhưng không thể hiểu sâu sắc nếu chỉ bắt đầu bằng mã UML cung cấp một ngôn ngữ đồ họa giúp xây dựng mô hình dễ hiểu hơn cho nhiều hệ thống, với ngữ nghĩa rõ ràng cho mỗi biểu tượng Điều này giúp các nhà phát triển và công cụ hỗ trợ mô hình hóa hiểu mô hình một cách chính xác.
UML là ngôn ngữ đặc tả giúp mô tả rõ ràng những điểm mấu chốt của vấn đề trong phát triển hệ thống phần mềm Nó cho phép xây dựng mô hình chính xác, không nhập nhằng và hoàn thiện, đồng thời hỗ trợ trong thiết kế, phân tích và quyết định cài đặt.
2.1.1.4 - UML là ngôn ngữ đễ xây dựng
UML không phải là ngôn ngữ lập trình trực quan, nhưng mô hình của nó có thể kết nối trực tiếp với các ngôn ngữ lập trình như Java, C++ và các hệ quản trị cơ sở dữ liệu Điều này cho phép ánh xạ mô hình UML sang các ngôn ngữ lập trình khác nhau, tạo ra khả năng biến đổi từ mô hình sang mã nguồn và ngược lại Nhờ đó, việc làm việc với văn bản và đồ họa trở nên nhất quán và dễ dàng hơn.
2.1.1.5 - UML là ngôn ngữ tài liêu
UML là công cụ hữu ích trong việc tạo tài liệu kiến trúc hệ thống và các chi tiết liên quan Nó cho phép biểu diễn yêu cầu, thực hiện thử nghiệm, và mô hình hóa các hoạt động lập kế hoạch cũng như quản lý sản phẩm hiệu quả.
UML cho biết giới hạn của hệ thống và các chức năng chính của nó thông qua
Trong UML, các UC đƣợc mô tả bằng biểu đồ logic
Biểu diễn cấu trúc tĩnh của hệ thống nhờ biểu đồ lớp
Mô hình hóa hành vi của đối tượng thông qua biểu đồ chuyển trạng thái giúp hiểu rõ hơn về cách thức hoạt động của hệ thống Đồng thời, việc phản ánh kiến trúc cài đặt vật lý qua biểu đồ thành phần và biểu đồ triển khai cung cấp cái nhìn tổng quan về cấu trúc và mối quan hệ giữa các thành phần trong hệ thống.
Mở rộng các chức năng bằng stereotypes
MÔ HÌNH KHÁI NIỆM CỦA UML
Để hiểu UML, cần hình dung mô hình khái niệm của ngôn ngữ này, bao gồm ba vấn đề chính: các phần tử cơ bản để xây dựng mô hình, quy tắc liên kết các phần tử và một số cơ chế chung Khi nắm vững những vấn đề này, bạn có thể đọc và tạo ra một số mô hình UML cơ bản.
2.2.1 - Phần tử mô hình trong UML
Mô hình UML được cấu thành từ ba loại khối: phần tử, quan hệ và biểu đồ Phần tử là các trừu tượng cơ bản, trong khi quan hệ kết nối các phần tử này với nhau; biểu đồ nhóm lại các phần tử UML bao gồm bốn loại phần tử mô hình: cấu trúc, hành vi, nhóm và chú thích, tạo thành các khối xây dựng cho phương pháp lập trình hướng đối tượng.
Phần tử cấu trúc trong mô hình UML bao gồm các danh từ, đóng vai trò là bộ phận tĩnh để thể hiện các thành phần khái niệm hoặc vật lý Mô hình này có bảy loại phần tử cấu trúc được mô tả cụ thể như sau:
Lớp là một tập hợp các đối tượng có chung thuộc tính, thao tác, quan hệ và ngữ nghĩa Mỗi lớp có thể cài đặt một hoặc nhiều ghép nối Hình 2.1 minh họa đồ họa lớp dưới dạng hình chữ nhật, thường bao gồm tên, thuộc tính và thao tác của lớp.
Giao diện Giao diện là tập hợp các thao tác làm dịch vụ của lớp hay thành phần
Giao diện mô tả hành vi của thành phần từ bên ngoài, thể hiện toàn bộ hoặc một phần hành vi của lớp Nó định nghĩa tập đặc tả thao tác mà không quy định cài đặt cụ thể Ký pháp đồ họa của giao diện được minh họa trong hình 2.2 Thông thường, giao diện không hoạt động độc lập mà được liên kết với lớp hoặc thành phần thực hiện nó.
Hình 2.1 Lớp Hình 2.2 Giao diện
Phần tử cộng tác là một yếu tố quan trọng trong việc mô tả ngữ cảnh tương tác, được biểu diễn bằng hình elip với đường viền nét đứt và tên gọi tương ứng Nó thể hiện giải pháp thi hành nội bộ của hệ thống, bao gồm các lớp, mối quan hệ và tương tác giữa chúng, nhằm đạt được chức năng mong đợi của UC.
Hình 2.3 Cộng tác Hình 2.4 Use case
Trường hợp sử dụng (Use case) mô tả trình tự các hành động mà hệ thống thực hiện để đạt được kết quả cho tác nhân bên ngoài Tác nhân tương tác với hệ thống, và tập hợp các UC sẽ tạo thành các trường hợp sử dụng của hệ thống Việc sử dụng UC giúp cấu trúc các phần tử hành vi trong mô hình, được hiện thực hóa bởi các phần tử cộng tác Hình 2.4 minh họa ký pháp đồ họa của UC.
Lớp tích cực (active class) là lớp mà đối tượng làm chủ một hoặc nhiều lớp tiến trình hoặc luồng Lớp này được coi là lớp thông thường nhưng biểu diễn các thành phần có hành vi đang cạnh tranh với các thành phần khác Ký pháp đồ họa của lớp tích cực tương tự như lớp thông thường, với biên chữ nhật được tô đậm Thông thường, lớp tích cực cũng có tên, thuộc tính và thao tác riêng.
Thành phần là yếu tố thể hiện vật lý mã nguồn và các tệp nhị phân trong quá trình phát triển hệ thống, với ký pháp đồ họa được minh họa trong hình 2.5.
Nút (node) là thành phần vật lý tồn tại trong quá trình chương trình chạy, đại diện cho các tài nguyên tính toán Các thành phần trên nút có thể được chuyển giao giữa các nút khác nhau, và nút có thể là máy tính hoặc thiết bị phần cứng Ký pháp đồ họa của các nút được mô tả trong hình 2.6.
Hình 2.5 Cộng tác Hình 2.6 Use case
Phần tử hành vi trong mô hình UML là các thành phần động, thể hiện hành vi theo thời gian và không gian Chúng được phân thành hai loại chính: tương tác và trạng thái.
Tương tác là hành vi bao gồm việc trao đổi thông điệp giữa các đối tượng trong một ngữ cảnh cụ thể nhằm đạt được mục đích nhất định Hành vi này có thể được thể hiện qua các thao tác của nhóm đối tượng, với biểu đồ thông điệp minh họa bằng mũi tên và tên của thao tác, như được trình bày trong hình 2.7.
Hình 2.7 Thông điệp Hình 2.8 Trạng thái
Máy trạng thái là một công cụ mô tả trật tự các trạng thái mà đối tượng hoặc tương tác trải qua để phản ứng với các sự kiện Hành vi của lớp hoặc sự cộng tác giữa các lớp có thể được xác định thông qua máy trạng thái Nó bao gồm nhiều phần tử như trạng thái, chuyển tiếp giữa các trạng thái, sự kiện và các hoạt động nhằm đáp ứng các sự kiện đó Ký pháp đồ họa của máy trạng thái được thể hiện rõ ràng, bao gồm tên và trạng thái con nếu có.
Phần tử nhóm trong mô hình UML là một bộ phận tổ chức quan trọng, với gói (package) là thành phần duy nhất thuộc nhóm này Gói hoạt động như một cơ chế linh hoạt để tổ chức các phần tử, bao gồm cấu trúc, hành vi và ngay cả phần tử nhóm Khác với thành phần (component), phần tử nhóm chỉ tồn tại trong giai đoạn phát triển hệ thống và không hiện hữu trong thời gian chạy chương trình Ký pháp đồ họa của nhóm được thể hiện qua hình 2.9, cho phép người dùng quan sát hệ thống ở mức tổng quan hơn.
Phần tử chú thích trong mô hình UML là bộ phận dùng để giải thích và mô tả các phần tử khác Chúng được gọi là ghi chú (note) và có ký pháp đồ họa như thể hiện trong hình 2.9.
Hình 2.9 Nhóm và lời ghi chú
2.2.2 - Các quan hệ trong UML
KIẾN TRÚC HỆ THỐNG
Kiến trúc phần mềm là sự trừu tượng hóa các khía cạnh quan trọng nhất của hệ thống, cung cấp khung cho thiết kế và mô tả quy mô, sức mạnh của hệ thống Nó thu thập các yêu cầu ứng dụng và các use case quan trọng, đồng thời thể hiện cách tổ chức phần mềm và cung cấp giao thức cho việc trao đổi dữ liệu giữa các mô-đun Việc hiển thị, đặc tả, xây dựng và tài liệu hóa hệ thống phần mềm cần được xem xét từ nhiều góc độ khác nhau, vì người sử dụng, nhà phân tích, nhà phát triển, và các bên liên quan có cách nhìn khác nhau vào các thời điểm khác nhau Kiến trúc hệ thống là yếu tố quan trọng nhất để quản lý các quan điểm khác nhau, điều khiển phát triển hệ thống một cách lặp đi lặp lại trong suốt vòng đời của nó, và nó bao gồm tập hợp các quyết định chiến lược.
Tổ chức của hệ thống phần mềm
Lựa chọn các phần tử cấu trúc và giao diện cho hệ thống
Hành vi của chúng thể hiện trong hợp tác giữa các phần tử
Tổ hợp các phần tử cấu trúc và hành vị vaò hệ thống con lớn hơn
Kiến trúc phần mềm không chỉ liên quan đến cấu trúc và hành vi mà cả chức năng, tính sử dụng lại, dễ hiểu, ràng buộc công nghệ …
Hình 2.24 Mô hình hóa kiến trúc hệ thống
Kiến trúc hệ thống phần mềm được thể hiện qua các khung nhìn, mỗi khung nhìn phản ánh tổ chức và cấu trúc của hệ thống, tập trung vào những khía cạnh cụ thể khác nhau.
According to Philippe Krutchen's diagram, there are five views in software architecture: the Use Case View, Logical View, Implementation View, Deployment View, and Process View Each view serves a distinct purpose in the overall design and understanding of the system.
Khung nhìn này, được hình thành từ giai đoạn phân tích yêu cầu, đóng vai trò quan trọng trong việc điều khiển và thúc đẩy các phần còn lại của thiết kế Nó mô tả hành vi của hệ thống từ góc nhìn của khách hàng, giúp đảm bảo rằng các yêu cầu và mong đợi của người dùng được đáp ứng một cách hiệu quả.
Khung nhìn Use Case (UC) là công cụ quan trọng cho các nhà phân tích và kỹ sư trong việc kiểm tra và thử nghiệm hệ thống Nó bao gồm các tác nhân, các trường hợp sử dụng (UC) và biểu đồ UC, phản ánh khía cạnh tĩnh của hệ thống Ngoài ra, khung nhìn UC cũng có thể bao gồm biểu đồ trình tự và biểu đồ cộng tác, đại diện cho khía cạnh động Mục tiêu của khung nhìn UC là cung cấp cái nhìn tổng quát về chức năng mà hệ thống sẽ thực hiện, mà không đi sâu vào cách thức hoạt động của nó, và không xác định cấu trúc tổ chức của hệ thống.
Khi bắt đầu dự án, khách hàng, phân tích viên và người quản lý dự án hợp tác với biểu đồ UC và tài liệu UC để thống nhất về hệ thống Sau khi khách hàng đồng ý về các UC và tác nhân, họ sẽ xác định phạm vi hệ thống Hệ thống sau đó sẽ được phát triển dựa trên khung nhìn logic.
Khung nhìn logic, được gọi bởi Rose, thể hiện tổ chức của các lớp quan trọng và mối quan hệ giữa chúng Nó tập trung vào cách hệ thống cài đặt hành vi trong Use Case (UC), bao gồm các lớp, biểu đồ lớp, biểu đồ đối tượng (khía cạnh tĩnh), biểu đồ tương tác, và biểu đồ biến đổi trạng thái (khía cạnh động), cùng với các gói Khung nhìn logic thu hút sự quan tâm của hầu hết mọi người trong dự án.
Đội ngũ phát triển phần mềm thường tiếp cận khung nhìn logic qua hai bước Bước đầu tiên là xác định các lớp phân tích (analysis class), những lớp này không phụ thuộc vào ngôn ngữ lập trình Trong UML, các lớp này được biểu diễn bằng các biểu tượng cụ thể.
Lớp phân tích xuất hiện trong biểu đồ tương tác của khung nhìn UC, và khi được nhận diện, chúng sẽ được chuyển giao cho lớp thiết kế (design class) bởi đội ngũ phát triển phần mềm, với các lớp này phụ thuộc vào ngôn ngữ lập trình.
Khung nhìn logic chú trọng vào cấu trúc logic của hệ thống, giúp xác định các bộ phận của hệ thống và khảo sát thông tin, hành vi cùng mối quan hệ giữa chúng Cần thận trọng trong việc gán thông tin và hành vi cho từng lớp, nhóm lớp, cũng như khảo sát quan hệ giữa các lớp và gói để đảm bảo khả năng sử dụng lại hiệu quả.
Rose định nghĩa khung nhìn thành phần (component view) là một cách tiếp cận trong việc phân tích hệ thống, trong đó thành phần được xem như là các mô-đun vật lý hoặc tiệp mã trình Khung nhìn này bao gồm các yếu tố chính như thành phần, biểu đồ thành phần và gói, giúp tổ chức và cấu trúc hệ thống vật lý một cách hiệu quả.
Người quản lý mã trình, dích chương trình và triển khai ứng dụng là những người quan tâm hàng đầu đến khung nhìn thành phần Các thành phần này bao gồm thư viện, mã trình khả thực (exe) và thư viện động (dll).
Khung nhìn triển khai tập trung vào việc phân bổ vật lý tài nguyên và nhiệm vụ giữa các tài nguyên trong hệ thống Nó khác với kiến trúc logic, ví dụ như hệ thống có kiến trúc ba tầng logic với giao diện, logic và tác nghiệp, cũng như logic CSDL tách biệt Tuy nhiên, trong thực tế, triển khai có thể chỉ gồm hai tầng, khi logic tác nghiệp và logic CSDL được đặt trên cùng một máy Khung nhìn triển khai cũng bao gồm các yếu tố như tiến trình, bộ xử lý và thiết bị, cho phép tối ưu hóa hiệu suất của hệ thống.
Khung nhìn triển khai mô tả các tiến trình và thiết bị trong mạng cùng với các kết nối vật lý giữa chúng Biểu đồ triển khai không chỉ thể hiện các tiến trình mà còn chỉ rõ tiến trình nào đang hoạt động trên từng máy.
Khung nhìn tiến trình biểu diễn cách các luồng thực hiện chương trình tương tác và đồng bộ hóa với nhau, đồng thời phân bổ các đối tượng và lớp cho từng luồng Nó tập trung vào việc mô tả các nhiệm vụ tương tranh trong hệ thống đa nhiệm Tuy nhiên, trong biểu đồ của phần mềm công cụ Rose 2000, khung nhìn này không được thể hiện.
2.3.6 - Cần bao nhiêu khung nhìn
RATIONAL ROSE LÀ GÌ?
Rational Rose là một công cụ mạnh mẽ hỗ trợ phân tích và thiết kế hệ thống phần mềm theo hướng đối tượng Phần mềm này cho phép mô hình hóa hệ thống trước khi tiến hành viết mã, từ đó đảm bảo tính chính xác và hợp lý của kiến trúc hệ thống ngay từ giai đoạn khởi đầu của dự án.
Mô hình Rose là một bức tranh tổng thể của hệ thống, bao gồm tất cả các yếu tố như biểu đồ UML, tác nhân, trường hợp sử dụng, đối tượng, lớp, thành phần và các nút triển khai trong hệ thống.
Bài viết mô tả chi tiết về hệ thống, bao gồm cách cài đặt và hoạt động của các thành phần, nhằm cung cấp cho nhà phát triển một kế hoạch chi tiết để xây dựng hệ thống Rose hỗ trợ giải quyết vấn đề giao tiếp giữa đội ngũ dự án và khách hàng, cũng như trong việc tạo lập tài liệu yêu cầu.
Theo phong cách lập trình truyền thống, sau khi xác định yêu cầu hệ thống, các nhà phát triển thường chọn một số yêu cầu để thiết kế và viết mã, dẫn đến khó khăn trong việc hiểu và quản lý toàn bộ hệ thống Nếu không có tài liệu thiết kế, việc đảm bảo rằng hệ thống xây dựng đúng như mong đợi của người sử dụng trở nên khó khăn Mặc dù các yêu cầu được ghi chép đầy đủ, nhưng thiết kế thường chỉ tồn tại trong đầu một nhà phát triển, khiến những người khác không có cái nhìn rõ ràng về cấu trúc hệ thống Nếu nhà phát triển rời đi, dự án có thể gặp khó khăn nghiêm trọng Một phong cách phát triển khác yêu cầu rằng sau khi xác định yêu cầu, các thiết kế cần được tài liệu hóa chi tiết, và mọi người tham gia phát triển cần trao đổi về quyết định thiết kế trước khi bắt đầu viết mã.
Dự án không còn lo lắng về việc ai đó rời bỏ, vì mọi thành viên đều có thể tiếp cận thông tin cần thiết từ mô hình, không chỉ riêng người phát triển hệ thống.
Khách hàng và quản lý dự án sử dụng biểu đồ UC để có cái nhìn tổng quát về hệ thống, từ đó thống nhất về phạm vi dự án.
Quản lý dự án sử dụng biểu đồ UC và tài liệu để chia nhỏ dự án thành tiểu dự án có thể quản lý đƣợc
Thông qua tài liệu UC, các phân tích viên và khách hàng thấy đƣợc các chức năng hệ thống sẽ cung cấp
Các phân tích viên và nhà phát triển sử dụng biểu đồ trình tự và biểu đồ công tác để hiểu rõ logic của hệ thống, các đối tượng trong hệ thống, và thông điệp giữa các đối tượng Đội ngũ kiểm tra chất lượng thu thập thông tin từ tài liệu UC và biểu đồ tương tác nhằm viết mô tả kiểm tra hệ thống một cách chính xác.
Các nhà phát triển sử dụng biểu đồ lớp và biểu đồ biến đổi trạng thái để hiểu rõ các phần của hệ thống và mối quan hệ giữa chúng Đội ngũ triển khai áp dụng biểu đồ thành phần và biểu đồ triển khai để xác định các tệp thực thi (exe), tệp DLL và các thành phần cần thiết, cũng như cách thức triển khai chúng trên mạng.
Đội ngũ dự án áp dụng mô hình nhằm đảm bảo rằng các yêu cầu có thể được chuyển đổi thành mã trình và ngược lại, cho phép mã trình được chuyển trở lại thành yêu cầu hệ thống.
Hơn nữa, Rational Rose còn hỗ trợ phát sinh mã khung chương trình trong nhiều ngôn ngữ khác nhau nhƣ C++, Java, Visual Basic, Oracle8 …
KHẢ NĂNG SỬ DỤNG UML
Mục tiêu của UML là mô tả mọi loại hệ thống thông qua các biểu đồ hướng đối tượng, giúp tóm tắt các đặc tính của hệ thống một cách rõ ràng và hiệu quả.
Các hệ thống thông tin đóng vai trò quan trọng trong việc lưu trữ, truy vấn và biểu diễn thông tin Chúng giúp quản lý khối lượng lớn thông tin với các mối quan hệ phức tạp, đặc biệt trong các cơ sở dữ liệu quan hệ và cơ sở dữ liệu hướng đối tượng.
Các hệ thống kỹ thuật đóng vai trò quan trọng trong việc quản lý và điều khiển các thiết bị như truyền tin, hệ thống quân sự và dây chuyền công nghiệp Những hệ thống này thường yêu cầu quản lý các giao diện người sử dụng đặc biệt mà không có phần mềm chuẩn Đặc biệt, phần lớn các hệ thống này hoạt động trong thời gian thực.
Các hệ thống nhúng thời gian thực được triển khai trên phần cứng đơn giản và tích hợp trong nhiều thiết bị như điện thoại di động, ô tô và các dụng cụ gia đình Những hệ thống này thường không có các thiết bị như màn hình hay ổ đĩa, điều này khiến chúng trở nên độc đáo và hiệu quả trong việc thực hiện các nhiệm vụ cụ thể.
Hệ thống phân tán hoạt động trên nhiều máy tính và yêu cầu cơ chế giao tiếp đồng bộ để đảm bảo tính toàn vẹn của dữ liệu Những hệ thống này thường được xây dựng dựa trên các cơ chế đối tượng như CORBA và COM/DCOM.
Các phần mềm hệ thống: Xác dịnh hạ tầng kỹ thuật để phần mềm khác sử dụng nhƣ hệ điều hành, CSDL…
Các hệ thống thương mại: Mô tả mục tiêu, tài nguyên (con người, máy tính…) và các quy luật (chiến lược thương mại, luật …) và qui trình thương mại
Ngày nay, hệ thống thường bao gồm nhiều loại hoặc tổ hợp các loại hệ thống khác nhau Dù vậy, chúng ta vẫn có thể sử dụng UML để mô hình hóa những hệ thống này một cách hiệu quả.
MÔ HÌNH HÓA TRƯỜNG HỢP SỬ DỤNG
PHÂN TÍCH TRƯỜNG HỢP SỬ DỤNG (USE CASE – UC)
Khái niệm UC đƣợc Ivar Jacobson đề xuất vào năm 1994 khi làm việc cho hãng
Eriction, hay còn gọi là Use Case (UC), mô tả cách người dùng tương tác với hệ thống phần mềm để thực hiện các nhiệm vụ cụ thể UC tập trung vào hành động của người sử dụng mà không đi sâu vào cách thức hoạt động bên trong của hệ thống Nó không phải là thiết kế hay kế hoạch cài đặt, mà là một phần của vấn đề cần giải quyết Quá trình của hệ thống được chia nhỏ thành các UC để nhận diện rõ ràng từng bộ phận, giúp nhiều người có thể cùng tham gia xử lý.
UC là nền tảng quan trọng trong phân tích hệ thống, giúp đảm bảo rằng hệ thống đáp ứng đầy đủ nhu cầu của người sử dụng Mỗi UC đại diện cho một tập hợp hành động, trong đó mỗi hành động thể hiện một chức năng mà hệ thống thực hiện, từ đó xác định mức độ hoàn thành của các yêu cầu.
3.1.2 - Xây dựng UC để làm gì?
Mục tiêu xây dựng UC trong tiến trình phát triển hệ thống phần mềm đƣợc tóm tắt nhƣ sau:
Quyết định và yêu cầu chức năng hệ thống được hình thành thông qua sự thỏa thuận giữa khách hàng và nhà phát triển phần mềm, đảm bảo rằng sản phẩm cuối cùng đáp ứng đúng nhu cầu và mong đợi của người sử dụng.
Hệ thống cần được mô tả một cách rõ ràng và nhất quán, đảm bảo rằng mô hình có thể được áp dụng xuyên suốt toàn bộ quá trình phát triển.
Cung cấp cơ sở để kiểm tra, thử nghiệm hệ thống
Cho khả năng dễ thay đổi hay mở rộng yêu cầu hệ thống
Hình 3.1 minh họa quy trình phân tích phần mềm từ góc độ hướng đối tượng, được xây dựng dựa trên các Use Case (UC) Tất cả các hoạt động trong các giai đoạn phân tích, thiết kế, cài đặt, kiểm tra và thử nghiệm chương trình đều gắn liền với UC.
Hình 3.1 UC và tiến trình phát triển
UC cung cấp một phương thức giao tiếp hiệu quả giữa các nhà phát triển, người dùng cuối và các chuyên gia trong lĩnh vực Hình 3.2 minh họa rõ ràng ai sẽ cần UC và mục đích sử dụng của nó Người dùng diễn đạt UC, trong khi kiến trúc sư thiết kế UC Các phân tích viên, lập trình viên và nhân viên kiểm tra chất lượng cũng cần hiểu rõ về UC để thực hiện công việc của mình một cách hiệu quả.
Hình 3.2 Ai quan tâm đến UC?
3.1.3 - Tìm kiếm UC nhƣ thế nào ?
Việc xác định và hiểu rõ các yêu cầu hệ thống thường gặp khó khăn do khối lượng thông tin khổng lồ, dẫn đến các yêu cầu thường được mô tả một cách lộn xộn, mâu thuẫn và thiếu chính xác Kết quả là một tập yêu cầu mờ, khó thay đổi Khái niệm UC được đưa ra để tập trung vào việc biểu thị các yêu cầu từ người sử dụng, nhấn mạnh rằng hệ thống được xây dựng chủ yếu cho người dùng Phân hoạch tập yêu cầu giúp giảm thiểu đáng kể độ phức tạp trong việc xác định yêu cầu.
Thu th ậ p, l ọ c và đ ánh giá UC
Ki ể m tra xem UC có th ỏ a mãn không
UC g ắ n các b ƣớ c trong ti ế n trình phát tri ể n
Hình 3.3 Phân hoạch yêu cầu bằng UC
Trong phương pháp hướng đối tượng, việc tìm kiếm UC (Use Case) bắt đầu bằng việc tham gia của khách hàng trong quá trình xây dựng Khách hàng có hiểu biết sâu sắc về cách hệ thống sẽ được sử dụng, do đó, phỏng vấn người sử dụng và khảo sát tài liệu là những phương pháp hiệu quả nhất để tìm kiếm UC Việc phỏng vấn cần sử dụng ngôn ngữ và khái niệm phù hợp với lĩnh vực của vấn đề và người sử dụng Phân tích viên cũng cần hợp tác chặt chẽ với các chuyên gia trong lĩnh vực và người quản lý dự án, vì các chuyên gia có kinh nghiệm sẽ giúp làm rõ cách người sử dụng tương tác với hệ thống Chất lượng phân tích phụ thuộc nhiều vào sự giao tiếp với các chuyên gia, do đó, cần ưu tiên việc trao đổi kỹ lưỡng Thường thì việc trao đổi này diễn ra độc lập để so sánh nhận thức và cách diễn đạt của người sử dụng và chuyên gia Nếu có sự khác biệt, cần tổ chức cuộc họp thảo luận để đạt được sự thống nhất Kết quả ban đầu từ quá trình này là các tác nhân và UC mức cao, mô tả yêu cầu chức năng của hệ thống Tuy nhiên, không phải người sử dụng nào cũng có khả năng diễn đạt rõ ràng cách họ muốn sử dụng hệ thống, vì vậy UC và biểu đồ UC trở thành công cụ hữu ích giúp người sử dụng diễn tả quan điểm của họ về hệ thống.
Trong quá trình tìm kiếm UC, tác nhân đóng vai trò quan trọng, là thực thể bên ngoài tương tác với hệ thống, có thể là con người hoặc thiết bị khác Tương tác này diễn ra thông qua việc trao đổi thông tin Tác nhân con người, như người sử dụng, thường là ví dụ điển hình; chẳng hạn, trong hệ thống ATM, khách hàng và người bảo trì đều là tác nhân Tác nhân không phải là người dùng cụ thể mà là lớp biểu diễn nhiệm vụ, ví dụ, độc giả là tác nhân trong quản lý thư viện, nhưng Anh Văn hay Chị Đào không phải Trong ngân hàng, hệ thống tín dụng quản lý thông tin tài khoản của khách hàng, và hệ thống ATM cần giao tiếp với hệ thống tín dụng, khiến nó trở thành tác nhân Thời gian cũng là một tác nhân quan trọng, xác định thời điểm xảy ra sự kiện trong hệ thống.
Một trong các kỹ thuật tìm kiếm tác nhân là trả lời các câu hỏi sau đây:
• Ai sẽ sử dụng các chức năng chính của hệ thống?
Ng ƣờ i dùng A Ng ƣờ i dùng C
• Ai giúp hệ thống làm việc hằng ngày?
• Ai quản trị, bảo dƣỡng để hệ thống làm việc liên tục?
• Hệ thống quản lý thiết bị phần cứng nào?
• Hệ thống đang xây dựng tương tác với hệ thống khác nào?
• Ai hay cái gì quan tâm đến kết quả hệ thống cho lại?
Sau khi có tác nhân, hãy trả lời các câu hỏi sau đây để tìm ra các UC:
• tác nhân yêu cầu hệ thống thực hiện chức năng gì?
• Tác nhân cần đọc, tạo lập, bãi bỏ, lưu trữ, sửa đổi các thông tin nào trong hệ thống?
• Có cần thông báo cho tác nhân về sự kiện xảy ra trong hệ thống? có cần tác nhân thông báo cái gì đó cho hệ thống?
• Hệ thống cần vào / ra nào? Vào / ra đi đến đâu hay từ đâu?
Sau khi xác định được UC, bước tiếp theo là gán tên cho chúng Hãy đặt tên cho UC dựa trên khái niệm tác nghiệp, tránh sử dụng thuật ngữ chuyên môn hay kỹ thuật Nên sử dụng động từ và câu ngắn gọn để tạo sự rõ ràng và dễ hiểu.
UC độc lập với cài đặt và ngôn ngữ lập trình, có thể được mô tả bằng Java, C++, văn bản giấy hoặc công cụ phần mềm như Rational Rose và Microsoft Modeler Mô tả UC bao gồm nhiều phần tử quan trọng.
• Khởi đầu UC - sự kiện khởi động UC Nó phải đƣợc mô tả rõ ràng, thí dụ, “UC bắt đầu khi X xảy ra”
• Kết thúc UC – sự kiện dừng UC Nó phải đƣợc nhận diện và làm tài liệu rõ ràng, thí dụ, “Khi Y xảy ra thì UC kết thúc”
• Tương tác giữa UC và tác nhân – mô tả rõ ràng cái bên trong hệ thống và cái bên ngoài hệ thống
Trao đổi thông tin giữa hệ thống và người sử dụng diễn ra thông qua các tham số tương tác Ví dụ, người sử dụng tương tác với hệ thống bằng cách nhập tên và mật khẩu để truy cập.
Hệ thống yêu cầu thông tin từ bên trong và bên ngoài trong những thời điểm cụ thể, tùy thuộc vào nhu cầu hoạt động và quản lý Khi thông tin được thu thập, hệ thống sẽ tiến hành lưu trữ chúng để đảm bảo khả năng truy cập và sử dụng sau này Việc này không chỉ giúp cải thiện quy trình làm việc mà còn nâng cao hiệu quả ra quyết định trong tổ chức.
• Lặp hành vi trong UC – có thể đƣợc mô tả bằng mã giả (pseudo – code)
• Tình thế phụ - phải đƣợc biểu diễn theo cách thống nhất giữa các UC
Mỗi hệ thống thường có từ 20-50 UC, với mỗi UC biểu diễn một giao dịch hoàn chỉnh giữa người sử dụng và hệ thống, nhằm mang lại kết quả cụ thể Sau khi xác định các UC, cần kiểm tra xem liệu tất cả đã được phát hiện đầy đủ hay chưa, 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 ở trong ít nhất một UC? Nếu yêu cầu chức năng không ở trong UC nào thì nó sẽ không đƣợc cài đặt sau này
• Đã xem xét mọi tác nhân tương tác với hệ thống?
• Tác nhân cung cấp cho hệ thống thông tin nào?
• Tác nhân nhận thông tin nào từ hệ thống?
• Đã nhận biết mọi hệ thống bên ngoài mà hệ thống này tương tác?
• Thông tin nào hệ thống bên ngoài nhận và gửi cho hệ thống này?
• Các UC vừa nhận ra từ hệ thống có đặc trƣng chính nhƣ sau:
UC luôn được kích hoạt bởi các tác nhân, có thể là trực tiếp hoặc gián tiếp, để hệ thống thực hiện các chức năng của UC Mối quan hệ giữa UC và các tác nhân này được thiết lập thông qua giao tiếp kết hợp.
• UC cung cấp giá trị trở lại cho tác nhân; giá trị là cái gì đó mà tác nhân muốn nhận đƣợc từ UC
• UC là hoàn chỉnh, nó đƣợc mô tả đầy đủ, không chia UC thành các UC nhỏ hơn
3.1.4 - Luồng sự kiện trong UC
BIỂU ĐỒ TRƯỜNG HỢP SỬ DỤNG
Mô hình UC trong UML được thể hiện qua nhiều biểu đồ UC, là công cụ hữu ích để thu thập yêu cầu hệ thống Các biểu đồ này giúp cải thiện giao tiếp giữa các phân tích viên hệ thống, người sử dụng và khách hàng Biểu đồ UC thể hiện mối quan hệ giữa các UC và các tác nhân, thường yêu cầu tạo ra nhiều biểu đồ cho một hệ thống Biểu đồ mức cao, Rational, là một ví dụ điển hình trong việc áp dụng mô hình này.
Biểu đồ chính (Main) do Rose gọi là biểu đồ đại diện cho gói hay nhóm UC, trong khi các biểu đồ khác thể hiện tập hợp các UC và tác nhân Số lượng biểu đồ UC trong một dự án có thể linh hoạt, nhưng lý tưởng là khoảng 50 cho các dự án lớn để đảm bảo thông tin đầy đủ mà không gây rối loạn Mục đích chính của biểu đồ UC là làm tài liệu cho tác nhân (các yếu tố bên ngoài hệ thống) và các quan hệ giữa chúng, cũng như các yếu tố bên trong phạm vi hệ thống Khi tạo lập UC, cần lưu ý một số điều quan trọng để đảm bảo hiệu quả.
Không nên mô hình hóa giao tiếp giữa các tác nhân, vì theo định nghĩa, tác nhân nằm ngoài hệ thống Do đó, giao tiếp giữa các tác nhân cũng nằm ngoài phạm vi của hệ thống đang xây dựng Thay vào đó, nên sử dụng biểu đồ luồng công việc (workflow) để khảo sát mối quan hệ này.
Trong hệ thống, không có quan hệ trực tiếp giữa hai trường hợp sử dụng (UC) trừ khi chúng có quan hệ sử dụng (Uses) hoặc quan hệ mở rộng (extends) Biểu đồ UC chỉ hiển thị các UC có trong hệ thống mà không chỉ ra thứ tự thực hiện của chúng Để xác định thứ tự thực hiện, cần sử dụng biểu đồ hoạt động.
• Mỗi UC phải được tác nhân khởi động, trừ trường hợp đặt biệt khi UC có quan hệ sử dụng hay mở rộng
CSDL đóng vai trò là lớp nền tảng cho toàn bộ biểu đồ UC, cho phép nhập dữ liệu qua một UC và truy xuất chúng thông qua UC khác mà không tạo ra luồng thông tin giữa các UC.
Hình 3.5 Các UC trừu tượng
Một UC không có tác nhân khởi động được gọi là UC trừu tượng, và nó cung cấp một số chức năng cho các UC khác Những UC này tham gia vào quan hệ Uses hoặc extends Hình 3.5 minh họa ví dụ về biểu đồ có sử dụng UC trừu tượng.
Tác nhân trừu tượng là những yếu tố không có hiện thực cụ thể, ví dụ như việc phân chia nhân viên trong một cơ quan thành ba nhóm: nhân viên hưởng lương tháng, nhân viên hưởng lương theo giờ và nhân viên hợp đồng Các loại nhân viên này được coi là các tác nhân trong hệ thống quản lý nhân sự, cho thấy rằng trong một cơ quan, không có ai được gọi đơn giản là Nhân viên mà phải xác định rõ ràng loại hình làm việc của họ.
Nhân viên hưởng lương tháng, Nhân viên hưởng lương giờ hay Nhân viên hợp đồng
Chúng ta có thể tạo ra một tác nhân nhân viên với những đặc điểm chung của ba loại nhân viên đã đề cập Tuy nhiên, hiện thực hóa tác nhân này vẫn chưa khả thi.
Xac thuc khach hang KhachHang
> là tác nhân trừu tƣợng hình 3.6 mô tả tác nhân trừu tƣợng và các quan hệ của nó với các tác nhân
Hình 3.6 Tác nhân trừu tượng
Trong UML, các kiểu quan hệ giữa Use Case (UC) và tác nhân bao gồm quan hệ giao tiếp, quan hệ sử dụng (Uses), quan hệ mở rộng (Extends) và quan hệ tổng quát hóa (Generalization) tác nhân.
Trong UML, quan hệ giao tiếp được thể hiện bằng các mũi tên Ví dụ, hình 3.7 mô tả mối quan hệ giữa tác nhân Khách hàng và hệ thống khi thực hiện chức năng Rút tiền Hình ảnh này cũng cho thấy rằng UC Rút tiền kích hoạt tác nhân Hệ thống thanh toán.
Quan hệ sử dụng (Uses) trong UML 1.3, còn gọi là quan hệ gộp (include), cho phép một UC sử dụng chức năng của UC khác Quan hệ này thường được áp dụng để mô hình hóa các chức năng tái sử dụng, phục vụ cho hai hoặc nhiều UC Ví dụ, trong hệ thống máy rút tiền tự động ATM, hai UC có thể chia sẻ các chức năng chung thông qua quan hệ Uses.
Để thực hiện giao dịch rút tiền và gửi tiền vào ngân hàng, cần xác định khách hàng và số căn cước cá nhân (PIN) Do đó, chức năng xác nhận này có thể được đặt trong một UC riêng, gọi là Xác nhận khách hàng Bất kỳ UC nào cần xác định khách hàng sẽ sử dụng chức năng này.
Hình 3.7 Quan hệ giao tiếp
Trong UML, quan hệ "Uses" được biểu diễn bằng mũi tên kèm theo từ khóa Hình 3.8 minh họa rằng hai trường hợp sử dụng (UC) là "Rút tiền" và "Gửi tiền" đều sử dụng chung một chức năng.
UC Xác nhận khách hàng UC Xác nhận khách hàng là UC trừu tƣợng Còn các UC
Rút tiền và Gửi tiền vào là các
UC cụ thể Các hình chữ nhật gấp góc là các chú thích của biểu đồ
Quan hệ mở rộng (extends) cho phép một Use Case (UC) mở rộng chức năng từ một UC khác, cho phép tái sử dụng các hành vi của UC tổng quát hơn Quan hệ này tương tự như quan hệ Uses, khi cả hai đều tách phần chức năng chung ra thành một UC trừu tượng mới Trong UML, quan hệ mở rộng được biểu diễn bằng mũi tên kèm theo từ khóa .
Hình 3.9 mô tả chức năng UC Rút tiền nhanh, được sử dụng khi khách hàng chọn thuộc tính rút nhanh cho số tiền không lớn (không quá 100.000đ) UC này cho phép bỏ qua một số thao tác ít quan trọng, đồng thời cung cấp chức năng mở rộng Trong khi Rút tiền là UC cụ thể, UC Rút nhanh lại là UC trừu tượng.
Hình 3.9 Quan hệ mở rộng