KHÁI QUÁT VỀ UML
GIỚI THIỆU UML
UML (Unified Modeling Language) 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 nền Web và hệ thống nhúng thời gian thực Với góc nhìn từ phát triển và triển khai hệ thống, UML dễ hiểu và dễ sử dụng cho cả con người và máy Phương pháp này giúp người dùng cấu trúc rõ ràng suy nghĩ và hành động, hướng dẫn họ về cách thực hiện công việc, thời điểm và lý do thực hiện Các mô hình trong phương pháp này được sử dụng để mô tả các khía cạnh khác nhau của hệ thống.
Sự khác biệt chính giữa phương pháp và ngôn ngữ mô hình hóa là ngôn ngữ mô hình hóa không cung cấp tiến trình cụ thể về cách thức thực hiện, thời điểm và lý do thực hiện các tác vụ Giống như các ngôn ngữ mô hình hóa khác, UML có ký pháp riêng, bao gồm các biểu tượng được sử dụng trong mô hình, cùng với một bộ luật quy định cách sử dụng chúng Những luật này bao gồm cú pháp, ngữ nghĩa và các quy tắc thực tiễn để tạo ra các câu có nghĩa.
Mặc dù nắm vững ngôn ngữ UML là điều cần thiết, nhưng điều đó không đảm bảo rằng bạn sẽ tạo ra một mô hình tốt Giống như một nhà văn tiểu thuyết sử dụng ngôn ngữ tự nhiên, ngôn ngữ chỉ là công cụ, và chất lượng tiểu thuyết phụ thuộc hoàn toàn vào tài năng của nhà văn Để sử dụng UML một cách hiệu quả, bạn cần hiểu rõ 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, đóng vai trò hỗ trợ cho các tiến trình nhưng không phụ thuộc vào chúng Nó đặc biệt phù hợp với các tiến trình hướng trường hợp sử dụng (Use Case - UC), tập trung vào kiến trúc và tương tác theo cách dần dần.
Ngôn ngữ cần có từ vựng và quy tắc tổ hợp để giao tiếp hiệu quả Ngôn ngữ mô hình, như UML, cung cấp từ vựng và quy tắc nhằm biểu diễn các khía cạnh vật lý và khái niệm của hệ thống UML là tiêu chuẩn công nghiệp cho lập kế hoạch phần mềm, nhưng không có mô hình nào phù hợp cho toàn bộ hệ thống; do đó, cần xây dựng nhiều mô hình khác nhau Ngôn ngữ UML cho phép biểu diễn nhiều khung nhìn của kiến trúc hệ thống trong quá trình phát triển phần mềm Tuy nhiên, nó không chỉ định mô hình nào cần được tạo ra và thời điểm nào; điều này phụ thuộc vào quy trình phát triển phần mềm, giúp xác định các sản phẩm, hoạt động và nhân viên liên quan, cũng như cách thức quản lý dự án tổng thể.
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 ngay lập tức cho các vấn đề có thể đơn giản, 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 gặp khó khăn khi không có ngôn ngữ chung Điều này đặc biệt khó khăn cho người mới tham gia dự án với ngôn ngữ riêng Mô hình hóa giúp hiểu rõ hơn các vấn đề hệ thống, chẳng hạn như phân cấp lớp, mà không thể nắm bắt đầy đủ chỉ bằng mã trình UML, với vai trò là ngôn ngữ đồ họa, hỗ trợ xây dựng mô hình dễ hiểu hơn so với ngôn ngữ lập trình, giúp cải thiện giao tiếp giữa các nhà phát triển và công cụ hỗ trợ Mỗi biểu tượng trong UML đều mang ngữ nghĩa rõ ràng, giúp người phát triển và các công cụ hiểu mô hình một cách chính xác.
UML (Unified Modeling Language) là một ngôn ngữ đặc tả giúp mô tả rõ ràng các điểm mấu chốt của vấn đề 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, hướng tới việc đặc tả thiết kế, phân tích và quyết định cài đặt trong quá trình phát triển và triển khai hệ thống phần mềm.
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ó khả năng kết nối trực tiếp với nhiều ngôn ngữ lập trình khác nhau như Java, C++ và các cơ sở dữ liệu quan hệ, hướng đối tượng Việc ánh xạ giữa mô hình UML và các ngôn ngữ lập trình cho phép chuyển đổi linh hoạt từ mô hình sang mã nguồn và ngược lại, giúp duy trì tính nhất quán trong việc làm việc với văn bản và đồ họa.
2.1.1.5 - UML là ngôn ngữ tài liêu
UML tập trung vào 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ó cung cấp khả năng biểu diễn yêu cầu, thực hiện thử nghiệm, cũng như mô hình hóa các hoạt động lập kế hoạch và 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 các hành vi đối tƣợng bằng biểu đồ chuyển trạng thái
Phản ảnh kiến trúc cài đặt vật lý bằng biểu đồ thành phần và biểu đồ triển khai
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 của ngôn ngữ Khi nắm vững những vấn đề này, người dùng có thể đọc và tạo ra các mô hình UML cơ bản.
2.2.1 - Phầntử mô hình trong UML
Mô hình UML bao gồm 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ử với nhau, và biểu đồ nhóm các phần tử lại Có bốn loại phần tử trong UML: cấu trúc, hành vi, nhóm và chú thích, những phần tử này đóng vai trò là các khối xây dựng cho mô hình hướng đối tượng cơ bản của UML.
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 để biểu diễn các thành phần khái niệm hoặc vật lý Có bảy loại phần tử cấu trúc được mô tả trong mô hình này.
Lớp là một tập hợp các đối tượng có cùng 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 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 là tập hợp các thao tác phục vụ cho lớp hoặc thành phần, mô tả hành vi bên ngoài của chúng Nó biểu diễn toàn bộ hoặc một phần hành vi của lớp, định nghĩa các thao tác mà không chỉ rõ cách cài đặt Giao diện thường không tồn tại độc lập mà được liên kết với lớp hoặc thành phần thực hiện các thao tác đó.
Hình 2.1 Lớp Hình 2.2 Giao diện
Phần tử cộng tác mô tả ngữ cảnh của tương tác trong hệ thống, được biểu diễn bằng hình elíp với đường nét đứt và kèm theo tên Nó thể hiện giải pháp thi hành bên trong 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ả chuỗi 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ương tác với nó Tập hợp các trường hợp sử dụng của hệ thống tạo thành các tình huống sử dụng cụ thể Việc sử dụng trường hợp sử dụng giúp cấu trúc các phần tử hành vi trong mô hình, và được hiện thực hóa thông qua các phần tử cộng tác Hình 2.4 minh họa ký pháp đồ họa của trường hợp sử dụng.
Lớp tích cực (active class) là loại lớp mà đối tượng của nó quản lý 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 đối tượng của nó thể hiện các thành phần có hành vi tương 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, nhưng hình chữ nhật được tô đậm để phân biệt 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ý trong hệ thống máy tính, tồn tại khi chương trình hoạt động và biểu thị các tài nguyên tính toán Các thành phần có thể được chuyển từ nút này sang nút khác, và nút có thể bao gồm máy tính hoặc thiết bị phần cứng Hình thức đồ họa của nút được minh họa 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 đóng vai trò quan trọng, thể hiện các động từ mô hình và diễn tả hành vi theo thời gian và không gian Chúng được chia thành hai loại chính: tương tác và trạng thái.
Tương tác là hành vi 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 đồ đồ họa minh họa thông điệp thông qua các mũi tên và tên thao tác, như thể hiện 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 sẽ trải qua để phản ứng với 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 để đáp ứng sự kiện Ký pháp đồ họa của máy trạng thái được thể hiện qua hình 2.8, bao gồm tên và các 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ế đa năng, cho phép tổ chức các phần tử cấu trúc, hành vi và cả phần tử nhóm vào trong một nhóm Khác với thành phần (component), phần tử nhóm chỉ tồn tại trong quá trình phát triển hệ thống và không có mặt trong thời gian chạy chương trình Ký pháp đồ họa của nhóm được thể hiện rõ ràng, giúp người dùng quan sát hệ thống từ một góc độ tổng quan hơn.
Phần tử chú thích trong mô hình UML là thành 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 đặc trưng, 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à xây dựng Nó mô tả quy mô, sức mạnh của hệ thống, và thu thập các yêu cầu quan trọng cùng các trường hợp sử dụng Kiến trúc thể hiện cách tổ chức phần mềm, cung cấp giao thức trao đổi dữ liệu và giao tiếp 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 yêu cầu xem xét từ nhiều khía cạnh khác nhau, vì mỗi người dùng (như người sử dụng cuối, nhà phân tích, nhà phát triển, và quản lý dự án) có cách quan sát 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, hỗ trợ phát triển hệ thống theo cách tăng dần và lặp lại trong suốt vòng đời của nó.
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 Mỗi khung nhìn tập trung vào một khía cạnh cụ thể, giúp người đọc hiểu rõ hơn về các thành phần và mối quan hệ trong hệ thống.
According to Philippe Krutchen's diagram [LIBE98], there are five distinct views in software architecture: the Use Case View, Logical View, Implementation View, Deployment View, and Process View Each view serves its own specific purpose, contributing to a comprehensive understanding of the system.
Khung nhìn này là cơ sở cho tất cả các khung nhìn khác và được hình thành từ giai đoạn phân tích yêu cầu Nó đó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ế, đồng thời mô tả các hành vi hệ thống từ góc nhìn của khách hàng.
Khung nhìn Use Case (UC) bao gồm các tác nhân, các trường hợp sử dụng và biểu đồ UC, phản ánh khía cạnh tĩnh của hệ thống Nó cũng có thể chứa các biểu đồ trình tự và biểu đồ cộng tác, thể hiện khía cạnh động của hệ thống Khung nhìn UC tập trung vào chức năng tổng quát của hệ thống 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 dự án khởi đầu, khách hàng, phân tích viên và người quản lý dự án hợp tác với các trường hợp sử dụng (UC), biểu đồ UC và tài liệu liên quan để đạt được sự đồng thuận 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 rõ ràng phạm vi của hệ thống Hệ thống sẽ tiếp tục được phát triển dựa trên khung nhìn logic đã thống nhất.
Khung nhìn logic, được Rose định nghĩa, 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 thực hiện hành vi trong trường hợp sử dụng (UC), bao gồm các thành phần như 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à nhận diện 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, đội ngũ phát triển phần mềm sẽ chuyển chúng sang lớp thiết kế Đây là các lớp 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, cho phép nhận diện các bộ phận, khảo sát thông tin và hành vi cũng như các mối quan hệ giữa chúng Việc gán thông tin và hành vi cho lớp, nhóm lớp, và khảo sát mối quan hệ giữa các lớp và gói cần được thực hiện cẩn thận để đảm bảo tính khả dụng lại của hệ thống.
Rose định nghĩa khung nhìn thành phần (component view) là cách tiếp cận mà trong đó thành phần được coi là các mô-đun vật lý hoặc tiệp mã trình, có thể kết hợp để tạo thành một hệ thống vật lý Khung nhìn này bao gồm các thành phần, biểu đồ thành phần và gói, giúp tổ chức và quản lý các yếu tố cấu thành hệ thống 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 nhất đế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ư một hệ thống có kiến trúc ba tầng bao gồm giao diện, logic tác nghiệp và logic cơ sở dữ liệu tách biệt Tuy nhiên, triển khai thực tế có thể chỉ cần hai tầng, với logic tác nghiệp và logic cơ sở dữ liệu trên cùng một máy Khung nhìn này còn bao gồm các yếu tố như tiến trình, bộ xử lý và thiết bị.
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ỉ ra vị trí chạy của từng tiến trình trên các máy khác nhau.
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, bao gồm tiến trình, luồng và nhiệm vụ, đồng thời đồng bộ hóa giữa các luồng và phân bổ đối tượng cho từng luồng khác nhau Nó tập trung vào việc mô tả các nhiệm vụ tương tranh và cách chúng tương tác 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 tiến trình này không được hiển thị.
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 bắt đầu viết mã, đả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 đầy đủ 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.
Hệ thống được mô tả chi tiết với các thành phần và cách thức hoạt động, giúp các nhà phát triển có một kế hoạch cụ thể cho việc xây dựng hệ thống Rose đóng vai trò quan trọng trong việc cải thiện giao tiếp giữa đội ngũ dự án và khách hàng, đồng thời hỗ trợ 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, người phát triển thường thiết kế và viết mã dựa trên một số yêu cầu nhất định Tuy nhiên, cách tiếp cận này gây khó khăn cho việc quản lý và hiểu rõ toàn bộ hệ thống, vì các quyết định thiết kế có thể không được ghi chép rõ ràng Nếu không có tài liệu thiết kế, việc đảm bảo rằng hệ thống được xây dựng đúng như mong đợi của người sử dụng trở nên khó khăn Dù yêu cầu có thể được tài liệu hóa đầy đủ, nhưng thiết kế thường chỉ tồn tại trong đầu của một vài người phát triển, dẫn đến việc thiếu thông tin cho những người khác Điều này có thể gây ra khó khăn cho dự án nếu người phát triển rời đi Một phong cách phát triển khác là yêu cầu rằng các thiết kế phải được ghi chép chi tiết sau khi xác định yêu cầu, 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 phải 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 quan trọng 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 quan về hệ thống, đồng thời 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 logic của hệ thống, các đối tượng trong hệ thống và thông điệp giữa chú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.
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õ hơn về cấu trúc và mối quan hệ giữa các phần của hệ thống Trong khi đó, độ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 khác 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 để đảm bảo rằng các yêu cầu có thể được chuyển đổi thành mã lập trình và ngược lại, cho phép mã lập 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 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à trực quan.
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 đảm nhiệm việc quản lý và điều khiển các thiết bị kỹ thuật như truyền tin, hệ thống quân sự và dây chuyền công nghiệp Chúng thường yêu cầu quản lý các giao diện người sử dụng đặc biệt, không sử dụng phần mềm chuẩn Đặc điểm nổi bật của các hệ thống này là chúng chủ yếu 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à được 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ị ngoại vi như màn hình hay ổ đĩa.
Hệ thống phân tán là những hệ thống hoạt động trên nhiều máy tính, 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 Chúng 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ủa các loại hệ thống khác nhau Tuy nhiên, chúng ta vẫn có thể sử dụng UML để mô hình hóa các 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 (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ể, mà không đi sâu vào cách hệ thống hoạt động bên trong UC không phải là thiết kế hay kế hoạch cài đặt, mà là một phần trong vấn đề cần giải quyết Quy trình của hệ thống được chia 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 được xây dự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 là một nhiệm vụ mà hệ thống thực hiện, có thể được thực hiện hoàn toàn hoặc chỉ một phần.
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 trình hình thành quyết định và mô tả yêu cầu chức năng của hệ thống là kết quả của 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 các yêu cầu được xác định rõ ràng và phù hợp với nhu cầu thực tế của người 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 mô hình có khả năng áp dụng xuyên suốt trong 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 tiến trình phân tích phần mềm từ góc nhìn hướng đối tượng, được xây dựng dựa trên các trường hợp sử dụng (UC) Mọi 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 các UC này.
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 sử dụng cuối cùng và các chuyên gia trong lĩnh vực Hình 3.2 minh họa những đối tượng cần UC và mục đích sử dụng của họ Người sử dụng diễn đạt UC, kiến trúc sư thiết kế UC, phân tích viên hiểu rõ UC, lập trình viên nắm bắt UC và nhân viên kiểm tra chất lượng thực hiện kiểm tra UC.
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 lớn và không có cấu trúc rõ ràng Điều này dẫn đến việc các yêu cầu bị mô tả lộn xộn, mâu thuẫn, thiếu sót và không chính xác, tạo ra một tập yêu cầu mờ khó thay đổi Khái niệm UC được đưa ra nhằm tập trung vào việc biểu thị các yêu cầu từ góc độ người dùng, nhấn mạnh rằng hệ thống được xây dựng chủ yếu phục vụ cho người sử 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 Cases) bắt đầu bằng sự tham gia của khách hàng, người hiểu rõ cách hệ thống sẽ được sử dụng Phỏng vấn người sử dụng và khảo sát tài liệu là cách hiệu quả nhất để thu thập thông tin Cần sử dụng ngôn ngữ và khái niệm phù hợp với lĩnh vực để phỏng vấn Phân tích viên nên hợp tác chặt chẽ với các chuyên gia và người quản lý dự án, vì họ có kinh nghiệm thiết kế sản phẩm tương tự và có thể cung cấp cái nhìn sâu sắc về 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 trao đổi kỹ lưỡng Việc trao đổi giữa người sử dụng và chuyên gia thường diễn ra độc lập để so sánh nhận thức và diễn đạt Nếu có sự khác biệt, cần tổ chức cuộc họp để đạt được sự đồng thuận Kết quả ban đầu là các tác nhân và UC mức cao được xác định, tuy nhiên, không phải người sử dụng nào cũng có khả năng mô tả rõ ràng mong muốn của mình UC và biểu đồ UC là 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.
Tiến trình tìm kiếm UC bắt đầu bằng việc xác định các tác nhân, là những thực thể bên ngoài tương tác với hệ thống, có thể là con người, hệ thống hoặc thiết bị phần cứng Tương tác giữa các tác nhân là sự trao đổi thông tin, trong đó tác nhân con người, như khách hàng trong hệ thống ATM hoặc độc giả trong quản lý thư viện, là ví dụ điển hình Tác nhân không chỉ đại diện cho người dùng cụ thể mà còn biểu diễn nhiệm vụ trong hệ thống Chẳng hạn, độc giả là tác nhân nhưng các cá nhân cụ thể như Anh Văn hay Chị Đào không phải là tác nhân Hệ thống tín dụng của ngân hàng quản lý thông tin tài khoản tín dụng của khách hàng và cần giao tiếp với hệ thống rút tiền tự động của ATM, khiến hệ thống tín dụng trở thành tác nhân Thời gian cũng đóng vai trò là tác nhân khi 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 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 để đảm bảo tính rõ ràng và dễ hiểu.
UC là một khái niệm độc lập với ngôn ngữ lập trình, có thể được mô tả bằng nhiều ngôn ngữ như Java, C++, hoặc thông qua các công cụ phần mềm như Rational Rose hay Microsoft Modeler Mô tả UC bao gồm các thành phần cơ bản cần thiết để hiểu rõ chức năng và yêu cầu của hệ thố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 của mình.
Hệ thống thông tin yêu cầu dữ liệu từ cả bên trong và bên ngoài trong những thời điểm cụ thể để đảm bảo hoạt động hiệu quả Việc thu thập thông tin này diễn ra khi có nhu cầu phân tích hoặc ra quyết định Ngoài ra, hệ thống cũng lưu trữ thông tin quan trọng để phục vụ cho các mục đích truy xuất và báo cáo trong tương lai.
• 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 bao gồm từ 20 đến 50 trường hợp sử dụng (UC), với mỗi UC biểu diễn một giao dịch hoàn chỉnh giữa người dùng và hệ thống, nhằm cung cấp một kết quả cụ thể Sau khi xác định các UC, cần kiểm tra xem tất cả đã được phát hiện đầy đủ hay chưa 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 đến tính toàn diện của các UC trong hệ thống.
• 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ụ quan trọng để 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, đồng thời chỉ ra mối quan hệ giữa các UC và tác nhân Thông thường, cần tạo ra nhiều biểu đồ UC cho một hệ thống, trong đó biểu đồ chính (Main) thể hiện gói hoặc nhóm UC, còn các biểu đồ khác chỉ ra tập hợp UC và tác nhân Số lượng biểu đồ UC trong một dự án có thể linh hoạt, nhưng tốt nhất là khoảng 50 cho dự án lớn, nhằm đả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à tài liệu hóa các tác nhân bên ngoài và các UC bên trong phạm vi hệ thống cùng với mối quan hệ giữa chúng Một số điểm cần lưu ý khi tạo lập UC cũng rất quan trọng.
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 không thuộc 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 mô hình sử dụng trường hợp (UC), không có quan hệ trực tiếp giữa hai UC, trừ khi chúng có mối quan hệ sử dụng hoặc mở rộng Biểu đồ UC chỉ ra các UC có trong hệ thống mà không chỉ rõ thứ tự thực hiện của chúng Để xác định thứ tự này, 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 hoạt động như một lớp cơ sở cho toàn bộ biểu đồ UC, cho phép nhập dữ liệu thông qua một UC và sử dụng UC khác để truy cập dữ liệu đó Tuy nhiên, không có luồng thông tin trực tiếp giữa các UC.
Hình 3.5 Các UC trừu tượng
UC trừu tượng là một trường hợp không có tác nhân khởi động, cung cấp chức năng cho các UC khác và tham gia vào quan hệ Uses hoặc extends Ví dụ về UC trừu tượng có thể thấy trong biểu đồ Tương tự, tác nhân trừu tượng là những tác nhân không có hiện thực, chẳng hạn 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 Trong hệ thống quản lý nhân sự, không có khái niệm chung về "Nhân viên", mà chỉ có các loại nhân viên cụ thể như đã nêu.
Tuy nhiên, chúng ta có thể xây dựng 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 Dù vậy, vẫn chưa có thực tế nào cho thấy sự tồn tại của tác nhân nhân viên này.
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) đối với tác nhân.
Trong UML, quan hệ giao tiếp được biểu thị bằng mũi tên Ví dụ, hình 3.7 minh họa 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 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.
Trong phiên bản UML 1.3, quan hệ Uses, còn được gọi là quan hệ gộp (include), cho phép một Use Case (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 những chức năng tái sử dụng, phục vụ cho hai hoặc nhiều UC Ví dụ, trong trường hợp máy rút tiền tự động (ATM), quan hệ này minh họa cách mà các chức năng có thể được chia sẻ giữa các UC khác nhau.
Để 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 Mọi UC cần xác định khách hàng đều có thể sử dụng UC này bất kỳ lúc nào.
Hình 3.7 Quan hệ giao tiếp
Trong UML, quan hệ "Uses" được thể hiệ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 vào đề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) trong UML cho phép một Use Case (UC) mở rộng chức năng từ một UC khác, nhằm tái sử dụng các hành vi chung Điều này có nghĩa là trong một số điều kiện nhất định, một UC có thể được mở rộng bởi một UC khác, 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 biểu đồ UML, quan hệ mở rộng được thể hiện bằng mũi tên kèm theo từ khóa .
Hình 3.9 mô tả quá trình UC Rút tiền, trong đó chức năng rút tiền nhanh chỉ hoạt động khi khách hàng chọn thuộc tính rút nhanh cho số tiền không lớn, chẳng hạn như không vượt quá 100.000đ UC Rút nhanh cho phép bỏ qua một số thao tác không quan trọng và cung cấp chức năng mở rộng UC này mang tính trừu tượng, trong khi Rút tiền là một UC cụ thể.
Hình 3.9 Quan hệ mở rộng
Quan hệ tổng quát hóa tác nhân là khái niệm được sử dụng để chỉ ra những điểm chung giữa các tác nhân khác nhau Ví dụ, trong một hệ thống, có hai loại khách hàng chính: khách hàng cá nhân và khách hàng tập thể Biểu đồ trong hình 3.10 minh họa sự phân loại này, trong đó khách hàng cá nhân và khách hàng tập thể được xem là những tác nhân cụ thể.
UC truu tuong định nghĩa tác nhân tổng quát là Khách hàng và phân loại chúng thông qua quan hệ tổng quát hóa, từ đó tạo ra các loại Khách hàng cá nhân và Khách hàng tập thể Tác nhân Khách hàng được coi là trừu tượng, có thể được chia nhỏ hơn, chẳng hạn như phân loại Khách hàng tập thể thành Công ty tư nhân và Tổ chức chính phủ, nhằm xây dựng quan hệ tổng quát hóa hiệu quả hơn.
Hình 3.10 Quan hệ tổng quát hóa tác nhân
