Chương 2 : Một số khái niệm cơ bản
2.4 UML trong phát triển phần mềm
Ngôn ngữ Mô hình thống nhất (UML-Unified modeling language) là chuẩn ngôn ngữ với mô hình chủ thể thế giới thứ ba. Hiện nay UML vẫn là yếu tố chuẩn cho mô hình hoá phần mềm. Có rất nhiều lý do người ta ứng dụng UML trong lĩnh vực phần mềm.
2.4.1 Mục tiêu của UML
Có thể nói rằng mô hình là một sự đơn giản hoá hiện thực. Mô hình được xây dựng để chúng ta dễ dàng hiểu và hiểu tốt hơn hệ thống cần xây dựng. [6]
Nói tóm lại, thông qua mô hình hóa giúp ta mô tả được mặt bản chất của một vấn đề hoặc một cấu trúc phức tạp bằng cách loại bỏ những chi tiết không quan trọng, khiến cho bài toán trở nên dễ hiểu và dễ nắm bắt hơn.
Việc biểu diễn mô hình thoả mãn các yếu tố sau:
Chính xác (accurate): Mô tả đúng hệ thống cần xây dựng.
Đồng nhất (consistent): Các view khác nhau không được mâu thuẫn
với nhau.
Có thể hiểu được (understandable): Cho cả người xây dựng lẫn sử
dụng
Dễ thay đổi (changeable)
Dễ dàng liên hệ với các mô hình khác.
Mục đích của UML là cho phép người dùng xác định được mô hình của hệ thống. Phần quan trọng của mô hình người dùng là định nghĩa các ngữ nghĩa của hệ thống đang được phát triển. Ngôn ngữ mô hình hóa thống nhất biểu diễn mô hình theo hướng đối tượng được xây dựng với mục đích là:
Mô hình hoá các hệ thống, sử dụng các khái niệm hướng đối tượng.
Thiết lập một kết nối từ nhận thức của con người đến các sự kiện cần
mô hình hoá.
Giải quyết vấn đề về mức độ thừa kế trong các hệ thống phức tạp, có
nhiều ràng buộc khác nhau.
Tạo một ngôn ngữ mô hình hoá có thể sử dụng được bởi người và
máy.
Cùng với việc sử dụng UML, người dùng tạo ra mô hình ứng dụng. Mục tiêu của nó là tạo ra một mô hình hoàn chỉnh, ổn định và chính xác. Nếu được thực
hiện đúng đắn, mô hình này có thể kiểm chứng được qua phân tích hoặc thực hiện và dùng để tạo ra các mức độ mã nguồn để triển khai hệ thống. Code có thể tự động tạo ra nếu ta dùng các công cụ như Rhapsody, hoặc công cụ tự viết ra. Việc mã code sinh tự động có rất nhiều ưu điểm như giảm nguồn lực và bảo trì tính ổn định giữa mô hình UML và mã lệnh, cả hai đều dùng để tạo nên hệ thống cuối cùng.
Hiện nay UML là yếu tố chuẩn áp dụng cho việc mô hình hoá phần mềm. Có rất nhiều cơ sở để khẳng định điều này:
Trước hết, UML có một mô hình ngữ nghĩa nền tảng được định
nghĩa rõ ràng, gọi là siêu mô hình UML. Mô hình ngữ nghĩa này vừa rộng (bao quát hầu hết các lĩnh vực cần thiết tiêu chuẩn kỹ thuật và thiết kế của hệ thống), vừa sâu (nghĩa là nó có thể tạo ra các mô hình có thể triển khai được hoặc có thể sử dụng để tạo ra các mức độ mã nguồn phục vụ cho việc chuyển đổi ngôn ngữ. Lập trình viên có thể dễ dàng có mô hình bất kỳ của hệ thống mà ta cần và thể hiện.
Thứ hai, UML dùng các ký hiệu rất chuyên nghiệp và dễ hiểu. Mặc dù
một số người cho rằng UML có quá nhiều đường biểu đồ, nhưng thực tế chỉ có một số được sử dụng thường xuyên như: biểu đồ cấu trúc (lớp), biểu đồ triển khai, biểu đồ trạng thái, biểu đồ hoạt động, biểu đồ các ca sử dụng và các biểu đồ tuần tự. Chúng hoạt động theo phương thức rõ ràng và theo một số nguyên tắc chung.
Thứ ba, UML được sử dụng là một chuẩn mà qua đó lập trình viên có
thể lựa chọn công cụ và dịch vụ từ rất nhiều nguồn khác nhau.
Cuối cùng, UML có khả năng ứng dụng. Trở thành ngôn ngữ mô hình
hoá hướng đối tượng thế giới thứ ba, chúng ta có kinh nghiệm hàng thập kỷ qua trong việc áp dụng các các phương thức hướng đối tượng vào hệ thống phát triển, bao gồm cả các hệ thống nhúng và hệ thống thời gian thực.
Ngày nay UML được sử dụng cho các mô hình và các hệ thống xây dựng với rất nhiều phạm vi từ đơn giản với thời gian phù hợp và nguồn lực quản lý ứng với các hệ thống nhúng và hệ thống thời gian thực. Điều đó có ý nghĩa khi các lập trình viên không dùng UML trong các hệ thống của họ, hệ thống sẽ gặp phải
2.4.2 Vai trò, vị trí của các lược đồ UML trong vòng đời phần mềm
UML có thể được sử dụng trong nhiều giai đoạn, từ phát triển, thiết kế cho tới thực thi và bảo trì. Vì mục đích chính của ngôn ngữ này là dùng các biểu đồ hướng đối tượng để mô tả hệ thống, nên miền ứng dụng của UML bao gồm nhiều loại hệ thống khác nhau như: Hệ thống thông tin, hệ thống kỹ thuật, hệ thống nhúng, hệ thống phân bố, hệ thống Giao dịch, phần mềm hệ thống.
UML có mặt trong hầu hết các giai đoạn phát triển hệ thống:
Nghiên cứu sơ bộ: use cases thể hiện các yêu cầu của người dùng. Phần miêu tả use case xác định các yêu cầu, phần diagram thể hiện mối quan hệ và giao tiếp với hệ thống.
Phân tích: Mục đích chính của giai đọan này là trừu tượng hóa và tìm hiểu
các cơ cấu có trong phạm vi bài toán. Class diagrams trên bình diện trừu tượng
hóa các thực thể ngoài đời thực được sử dụng để làm rõ sự tồn tại cũng như mối
quan hệ của chúng. Chỉ những lớp (class) nằm trong phạm vi bài toán mới đáng
quan tâm.
Thiết kế: Kết quả phần analysis được phát triển thành giải pháp kỹ thuật. Các lớp được mô hình hóa chi tiết để cung cấp hạ tầng kỹ thuật như giao diện, nền tảng cho database, … Kết quả phần Design là các đặc tả chi tiết cho giai đoạn xây dựng phần mềm.
Phát triển: Mô hình Design được chuyển thành code. Lập trình viên sử dụng các UML diagrams trong giai đoạn Design để hiểu vấn đề và tạo code.
Kiểm thử: Sử dụng các UML diagrams trong các giai đoạn trước. Có 4 hình thức kiểm tra hệ thống:
Kiểm thử đơn vị (class diagrams & class specifications) : kiểm tra từng đơn thể, được dùng để kiểm tra các lớp hay các nhóm đơn thể.
Kiểm thử tích hợp (integration diagrams & collaboration diagrams) :
kiểm tra tích hợp là kiểm tra kết hợp các cấu phần với các lớp để xem
chúng hoạt động với nhau có đúng không.
Kiểm thử hệ thống (use-case diagrams) : kiểm tra xem hệ thống có đáp ứng được chức năng mà người dùng yêu cầu hay không.
Kiểm thử chấp nhận: Kiểm tra tính chấp nhận được của hệ thống, thường được thực hiện bởi khách hàng, việc kiểm tra này thực hiện tương tự như kiểm tra hệ thống.
2.4.3 Các công cụ xây dựng UML
Rất nhiều công cụ trong thực tế chỉ thông minh hơn các chương trình vẽ một chút, sử dụng một vài quy chế kiểm tra tính nhất quán hoặc một vài kiến thức về phương pháp và ngôn ngữ mô hình hóa.
Cùng với sự ra đời của ngôn ngữ UML, các nhà cung cấp công cụ mô hình hóa giờ đây có thể dành nhiều thời gian hơn cho việc nâng cấp công cụ.
Mặc dù đã có một vài bước tiến nhất định và nhiều công cụ đã được sử dụng để nhằm mục đích hỗ trợ xây dựng UML như Rational Rose, GDPro, Visio, …,nhưng thị trường vẫn còn không ít công cụ chưa được gọt giũa, vẫn còn chứa lỗi hoặc những điểm bất hợp lý, kể cả những vấn đề đơn giản như copy và dán. Những công cụ này còn có hạn chế ở một số phương diện nhất định.
Tuy nhiên, một công cụ mô hình hóa hiện đại cũng cần phải đáp ứng được các chức năng sau:
Vẽ biểu đồ: Cần phải tạo điều kiện dễ dàng vẽ ra các biểu đồ trong ngôn ngữ mô hình hóa. Công cụ cần phải đủ khả năng thông minh để hiểu mục đích của các biểu đồ và biết được những ngữ nghĩa cũng như các quy tắc đơn giản, đủ để nó có thể cảnh báo hoặc ngăn chặn việc sử dụng không thích hợp các phần tử mô hình.
Hoạt động như một kho: công cụ cần phải hỗ trợ một kho trung tâm để tất cả các thông tin về mô hình được lưu trữ trong cùng một chỗ. Nếu ví dụ tên của một lớp bị thay đổi trong một biểu đồ, thì sự thay đổi này cần phải xảy ra trong tất cả các biểu đồ khác có sử dụng lớp này.
Hỗ trợ định hướng: công cụ cần phải tạo điều kiện dễ dàng cho người dùng định hướng và chuyển dịch trong mô hình để theo dõi một phần tử từ biểu đồ này sang biểu đồ khác, hoặc để mở rộng sự mô tả của một phần tử.
Hỗ trợ nhiều người dùng: Công cụ cần hỗ trợ cho nhiều người dùng, và tạo điều kiện cho họ cùng làm việc với một mô hình mà không ngăn chặn hoặc quấy phá lẫn nhau.
Tự động tạo code: một công cụ cao cấp cần phải có khả năng tạo ra code, nơi tất cả các thông tin trong mô hình được chuyển tải thành các khung code (code skeletons), được sử dụng làm nền tảng cho giai đoạn xây dựng chương trình.
Tái tạo mô hình: Một công cụ cao cấp cần phải có khả năng đọc những thành phần code đang tồn tại và từ đó sản xuất ra mô hình. Từ đó suy ra, một mô hình có thể được làm từ những dòng code đã tồn tại; hoặc một nhà phát triển có thể dễ dàng chuyển đi chuyển về giữa công việc mô hình hóa và công việc lập trình.
Tích hợp với các công cụ khác: một công cụ cần phải có khả năng tích hợp với những công cụ khác, với cả việc phát triển môi trường, ví dụ như các trình soạn thảo, chương trình dịch, chương trình tìm lỗi cũng như các công cụ của doanh nghiệp khác như công cụ quản trị cấu hình, hệ thống theo dõi các phiên bản.
Bao quát mô hình ở tất cả các mức độ trừu tượng hóa khác nhau: công cụ cần phải dễ chuyển tải từ lời miêu tả ở cấp trừu tượng hóa cao nhất của hệ thống (tức là ở dạng một lượng các gói khác nhau) đi xuống cho tới cấp của những dòng code thật sự. Sau đó, để truy xuất những dòng lệnh code cho một thủ tục cụ thể nào đó trong một lớp nào đó, bạn có thể chỉ cần nhấp chuột vào tên của thủ tục đó trong một biểu đồ.
Trao đổi mô hình: Một mô hình hay một biểu đồ của một mô hình nào đó
cần phải có khả năng được xuất ra từ một công cụ này rồi nhập vào một công cụ khác, giống như những dòng lệnh code được sản sinh trong một công cụ này có thể được sử dụng trong một công cụ khác. Nguyên tắc trao đổi đó cần phải được áp dụng cho các mô hình trong một ngôn ngữ mô hình hóa được định nghĩa chính xác
Như vậy, ta đặt ra câu hỏi là liệu có thể kiểm thử dựa trên các lược đồ UML? Tạo các lược đồ UML có rẻ hơn và dễ kiểm thử hơn cái phần mềm mà nó biểu diễn? Trong cả hai tình huống, câu trả lời không bao giờ rõ ràng. Không có phương pháp chắc chắn nào để kiểm tra các lược đồ UML. Chúng ta có thể nhìn chúng, định lượng chúng, áp dụng các nguyên tắc thiết kế và các mẫu thiết kế lên chúng, nhưng kết quả của việc đánh giá chúng vẫn rất chủ quan. Vẽ lược đồ UML thì dễ hơn là viết phần mềm, nhưng với hệ số không lớn. Thật vậy, thay đổi mã nguồn dễ hơn rất rất nhiều lần so với việc thay đổi một lược đồ. Tại sao ta nên sử dụng các công cụ UML? hay dùng công cụ xây dựng UML có phải là cách hợp lý không? Ta sẽ không sử dụng một mô hình UML nếu như dùng nó là không hợp lý. Tuy nhiên, những lập luận trên nhằm giải thích rằng UML rất dễ bị dùng sai mục đích. Chúng ta sử dụng UML khi chúng ta có một thứ gì đó mà chúng ta dứt khoát phải kiểm thử nó, và khi dùng UML để kiểm thử thì rẻ hơn là dùng mã nguồn để kiểm thử nó. Ví dụ, nói rằng tôi có một ý tưởng cho một thiết kế nào đó. Tôi muốn kiểm tra rằng liệu những thành viên trong nhóm của tôi có cho rằng đấy là một ý tưởng đúng đắn không. Vì vậy tôi vẽ lược đồ UML lên bảng và hỏi thành viên trong nhóm để nhận phản hồi.
Sau khi các thành viên đã thông qua ý tưởng trình bày (lược đồ UML), đội phát triển tiến hành thiết kế, lập trình và kiểm thử. Kiểm thử là khâu không thể thiếu trong quy trình phát triển phần mềm.