UML ( Unified Modeling Language) hay còn gọi là Ngôn ngữ mô hình hóa thống nhất, được xem như là ngôn ngữ mô hình hóa tiêu chuẩn trong việc phát triển hệ thống cũng như phần mềm. Tuyên bố trên đã chính thức kết thúc những tranh cãi xung quanh việc phát triển phần mềm tuy nhiên nó cũng đã để lại những câu hỏi chưa có lời giải đáp. Tại sao lại gọi là UML thống nhất? UML có thể mô hình những gì? Vì sao lại gọi UML là một ngôn ngữ ? Và điều quan trọng nhất là vì sao bạn phải quan tâm tới UML. Việc thiết kế một hệ thống có quy mô lớn đối mặt nhiều khó khăn, thách thức. Từ một ứng dụng cá nhân đơn giản cho tới hệ thống doanh nghiệp nhiều người dùng đều được tạo thành từ hàng trăm tới hàng ngàn thành phần phần mềm và phần cứng khác nhau. Làm sao bạn hay nhóm của bạn có thể theo dõi những thành phần cần thiết này, tác dụng của chúng, cũng như chúng có đáp ứng được yêu cầu của khách hàng. Xa hơn, làm sao bạn có thể chia sẻ thiết kế của mình với những đồng nghiệp khác mà chắc chắn rằng chúng vẫn còn hoạt động ăn khớp với nhau. Có quá nhiều chi tiết mà bạn có thể hiểu sai hoặc bỏ sót trong quá trình phát triển một hệ thống phức tạp khi mà trong tay bạn không có một công cụ hỗ trợ cần thiết. Và đây là lúc UML xuất hiện. Trong thiết kế hệ thống, bạn muốn mô hình hóa vì một lý do quan trọng: để quản lý sự phức tạp. Mô hình hóa giúp bạn có thể thấy một bức tranh tổng quát, cho phép bạn tập trung, nắm bắt, thảo luận về những khía cạnh quan trọng của hệ thống. Một mô hình là một định nghĩa trừu tượng của một đối tượng thực. Khi bạn mô hình hóa một hệ thống, bạn trừu tượng tất cả chi tiết, cả những chi tiết không liên quan hoặc có thể gây nhầm lẫn. Mô hình này là một bản sao chép đơn giản cho một hệ thống thực tế, vì vậy nó cho phép bạn hiểu, ước lượng hoặc đánh giá hệ thống nhanh hơn là việc đào sâu nghiên cứu chính hệ thống thực tế. Không những vậy, với một ngôn ngữ mô hình chính thức, tuy chỉ là việc trừu tượng, nhưng lại là một ngôn ngữ chính xác. Việc chính xác này cho phép máy tính có hiểu được, vì thế có thể phiên dịch, thực thi cũng như chuyển đổi qua lại giữa các hệ thống khác nhau. Để mô hình một hệ thống hiệu quả, bạn cần một thứ quan trọng. Đó là ngôn ngữ với các mô hình cụ thể. Đó chính là UML. 1.1 UML có những gì? UML bao gồm tập hợp những pseudo-code (mã giả), actual code (mã thật), hình ảnh, biểu đồ, những chú thích, và thực tế là chúng bao gồm nhiều thứ giúp bạn mô tả một hệ thống. Những thành phần tạo nên UML này được gọi là notation (những ký hiệu hay quy ước). Hình sau miêu tả một ví dụ về notation. Hình 1-1 trên là định nghĩa một class trong UML. Tuy nhiên, notation không phải toàn bộ UML. Nếu không được giải thích hình 1-1 là định nghĩa một lớp, tuy bạn có thể đoán ra nó là gì, nhưng vẫn không đầy đủ. Vì vậy việc mô tả notation là cần thiết. Những mô tả này được gọi là semantics (ngữ nghĩa học). Bất cứ thứ gì có notation ( thể hiện một mô hình) và có mô tả ý nghĩa của notation thì đều được gọi là ngôn ngữ mô hình hóa. Nhưng tại sao bạn lại được khuyên dùng UML trong khi có rất nhiều cách để mô hình hóa, bao gồm cả những cách bạn tự nghĩ ra? Mọi phương pháp mô hình hóa đều có ưu và khuyết điểm, nhưng UML có 6 ưu điểm sau: UML là một ngôn ngữ chính thức: mỗi thành phần trong UML đều được định nghĩa chuẩn xác, vì vậy bạn có thể tự tin rằng, khi bạn mô hình hóa một thành phần nào của hệ thống, nó sẽ không bị hiểu lầm. UML ngắn gọn: toàn bộ UML được tạo thành từ những ký hiệu đơn giản và dễ hiểu. UML toàn diện: UML mô tả đầy đủ các khía cạnh của một hệ thống UML linh động: Khi cần thiết UML có thể xử lý một hệ thống lớn, nhưng UML cũng có thể mô hình những hệ thống nhỏ. UML dễ học: UML đã được đưa vào giảng dạy trong cộng động hướng đối tượng từ 15 năm qua UML tiêu chuẩn: UML được kiểm soát tiêu chuẩn bởi một nhóm mở với sự đóng góp của nhiều kỹ sư và học viện trên toàn thế giới. Điều này đảm bảo UML có khả năng tương tác và hiểu được trên toàn thế giới 1.1.1 Mô hình hóa bằng code. Quá nhiều chi tiết và phức tạp Mã nguồn phần mềm là một ví dụ tiềm năng của mô hình hóa. Mỗi dòng code là chi tiết về các phần mềm hoạt động. Ví dụ sau thể hiện một lớp đơn giản trong Java, bao gồm nhiều chi tiết trong khai báo. Ví dụ 1-1. Hiển thị tất cả thông tin về lớp Guitarist, bao gồm cả quan hệ kế thừa của các lớp, biến thành viên liên quan đến lớp, cả thông tin chi tiết về cách hoạt động của các phương thức trong lớp. Vậy mô hình hóa bằng code có tốt không? Tất cả chi tiết đều có, mọi thành phần của code đều dễ hiểu đối với trình biên dịch, thêm vào ghi chú trong code, cùng với tài liệu đi kèm JavaDoc, không phải bạn đã có một bản thể hiện chính xác của hệ thống? Sự thật là bạn chưa mô hình hóa bất cứ thứ gì ngoài việc triển khai code cho hệ thống. Mã nguồn chỉ tập trung vào phần mềm và bỏ qua những phần còn lại của hệ thống. Mặc dù code đầy đủ và rõ ràng nhưng một mình mã nguồn thì không chỉ ra rằng ai là người sử dụng nó, sử dụng nó như thế nào, hoặc làm sao để triển khai code này, một bức tranh tổng quát đã bị thiếu nếu tất cả những gì bạn có chỉ là phần code. (ND: Trong bài dịch có lúc tôi dùng chữ mã nguồn, có lúc tôi giữ nguyên là code hoặc source code, tùy ngữ cảnh) Cũng như việc phớt lờ bức tranh lớn của hệ thống, code còn gặp phải vấn đề khi bạn muốn sử dụng một công nghệ khác để giải thích về hệ thống cho những người khác. Bạn phải có kiến thức về code để đọc và hiểu nó, tuy nhiên khách hàng và những bên liên quan lại không được như vậy. Những người này chỉ muốn tập trung vào những yêu cầu của họ, hoặc muốn thấy các thành phần trong hệ thống làm việc như thế nào để đáp ứng yêu cầu của họ. Bởi vì code được làm ra để mô tả cách thức phần mềm làm việc, nó không thể cung cấp một tầm nhìn với mức độ trừu tượng cao hơn cho hệ thống. Vì vậy code không thể phù hợp với các bên liên quan trong hệ thống của bạn. Bây giờ hãy hình dung nếu bạn triển khai hệ thống với nhiều ngôn ngữ phần mềm khác nhau. Vấn đề càng trở nên tồi tệ. Nó bắt buộc các bên liên quan phải am hiểu ngôn ngữ phần mềm trước khi hiểu được hệ thống của bạn. Cuối cùng, nếu thiết kế của bạn được mô hình hóa bằng code, bạn sẽ thất bại khi hệ thống bị tái sử dụng. Bởi vì thiết kế thường thay đổi, tái sử dụng, nhưng code thì không thể như vậy. (ND: thật ra hướng đối tượng hiện nay, với cách khai báo design-pattern; tôi đã có bài viết khác về vấn đề này; chúng ta vẫn có thể re-use code để đáp ứng yêu cầu mới của hệ thống) Tất cả những vấn đề nêu trên chứng tỏ một sự thật rằng, mô hình hóa bằng code chỉ cung cấp duy nhất một cấp độ của việc trừu tượng: đó là cấp độ triển khai phần mềm. Thật không may, chính vấn đề này làm cho code trở thành một ngôn ngữ mô hình nghèo nàn. 1.1.2 Mô hình hóa với các ngôn ngữ không chính thức: Rườm rà, mơ hồ và lẫn lộn. Đối nghịch với hình ảnh hoàn hảo và chính xác của mô hình hóa bằng code là những ngôn ngữ mô hình hóa không chính thức. Những ngôn ngữ này không có những ký hiệu được định nghĩa chính thức. Không có quy luật chính xác và nhanh chóng để hiểu ý nghĩa của ký hiệu, mặc dù đôi lúc cũng có kèm theo vài hướng dẫn. Một ví dụ tốt nhất về ngôn ngữ mô hình hóa không chính thức là ngôn ngữ tự nhiên. Ngôn ngữ tự nhiên là ngôn ngữ mà bạn đang đọc trong sách này. Nổi tiếng là có ý nghĩa mơ hồ. Việc diễn tả chính xác ý nghĩa của một điều gì đó cho người khác nghe thông qua việc nói chuyện là một thách thức thật sự và đôi khi là một nhiệm vụ bất khả thi. Chắc chắn rằng bạn đã từng nghe người đối diện nói rằng họ không hiểu những gì bạn nói, trong khi bạn đã huyên thuyên gãy cả lưỡi. Sau đây là ví dụ về việc sử dụng ngôn ngữ tự nhiên để thực hiện lại ví dụ 1-1 trên. Guitaristlà một lớp bao gồm 6 thành phần. 1 thành phần static và 5 thành phần non static. (ND: tác giả cho rằng độc giả là những người đã am hiểu ngôn ngữ hướng đối tượng) Trong lớp, có một biến cục bộ favoriteGuitar là một Guitar. 5 thành viên còn lại trong Guitarist là những phương thức. 4 trong đó là non static. Một còn lại là phần constructor (phần khởi tạo) nhận một thông số đầu vào... Nếu bạn nhìn kỹ vào phần định nghĩa trên, bạn có thể thấy đủ thứ vấn đề, hầu hết là kết quả của việc nhập nhằng trong ngôn ngữ. Sự mơ hồ này dẫn tới hội chứng là, “Không, đây không phải là ý của tôi”. Trong khi bạn cố gắng hết sức để giải thích rõ ràng một điều gì đó, nhưng người mà bạn truyền đạt ý tưởng thiết kế lại hiểu sai ý của bạn. Hình 1-2. Mô tả ngay cả việc sử dụng một ngôn ngữ tự nhiên đơn giản nhất cũng có thể bị hiểu khác nhau giữa những người liên quan làm việc trong hệ thống Ý nghĩa của hình 1-2 là: Người thiết kế cần một cái rương (trunk) có bốn chân (four legs), nhưng người triển khai lại hiểu là phải tìm một con voi ( có vòi là trunk (từ đồng nghĩa), bốn chân là four legs ) Hình 1.3 là một ví dụ khác về việc sử dụng ngôn ngữ không chính thức. Đây là những ký hiệu tôi thường sử dụng. Tôi hoàn toàn hiểu ý nghĩa của nó, nhưng chưa chắc bạn dễ dàng hiểu nó. Với việc mô hình bằng ngôn ngữ tự nhiên, những chi tiết trong hình 1-3 đều được thể hiện, nhưng nếu thiếu định nghĩa của những hộp vuông, đường nối… bạn có chắc là mình hiểu hết ý nghĩa của nó (hay ý của tôi) Vấn đề cơ bản trong ngôn ngữ không chính thức là chúng không có quy luật chính xác về các ký hiệu. Trong ví dụ hình 1-2, ý nghĩa của việc mô hình hóa đã bị hiểu sai do từ đồng nghĩa trong ngôn ngữ (trunk là cái rương, cũng là vòi con voi) Bởi vì ngôn ngữ mô hình không chính thức thiếu sự chính xác, chúng không thể chuyển thành code giống như một ngôn ngữ mô hình chính thức. Hãy hình dung nếu hình 1-3 có một tập hợp các quy luật chính thức, sau đó bạn có thể phát triển code để triển khai các lớp Guitaris, Person.. Nhưng những điều trên là không thể nếu thiếu một tập hợp các quy ước. 1.1.3 Giải pháp dung hòa: Chọn một ngôn ngữ chính thức Bạn đã nhìn thấy những cạm bẫy trong việc sử dụng code (quá chi tiết) và ngôn ngữ tự nhiên rườm rà, mơ hồ để mô hình hóa. Lý tưởng nhất là, một ngôn ngữ mô hình chính thống với hệ thống ký hiệu được định nghĩa rõ ràng. Hệ thống ký hiệu này phải nhỏ gọn, dễ học, và khó gây lầm lẫn. UML chính là ngôn ngữ như vậy. Hình 1-5 sau, thể hiện lại cấu trúc code trong ví dụ 1-1 bằng UML. Hiện tại bạn không cần lo lắng về ký hiệu và ý nghĩa của chúng. Bạn sẽ hiểu chúng sau khi đọc xong cuốn sách này. Hiện tại tôi chỉ muốn so sánh giữa ngôn ngữ không chính thức và UML. Mặc dù bạn không hiểu hoàn toàn những ký hiệu trong hình 1-5, nhưng bạn có thể bắt đầu hiểu rằng một số chi tiết trong phần ví dụ 1-1 đã không được nhắc tới ở đây. Ví dụ phương thức play() đã bị trừu tượng hóa, giúp bạn có thể hình dung cấu trúc bớt lộn xộn hơn rất nhiều. Một điều tuyệt vời nhất khi mô hình hóa hệ thống với UML là các ký hiệu trong hình 1-5 đều được định nghĩa sẵn và cụ thể. Nếu bạn đem biểu đồ này tới một người khác trong hệ thống (giả định rằng anh ta biết UML), thiết kế này sẽ được hiểu chính xác. Đây là thuận lợi của việc sử dụng một ngôn ngữ mô hình chính thức. Ví dụ hình 1.6 sau: Hình 1-6: với ngôn ngữ mô hình hóa được định nghĩa đầy đủ , bạn có thể chắc chắn rằng mọi người sẽ đọc bức tranh trên theo cùng một cách. 1.2 Tại sao lại là UML2.0? Phiên bản đầu tiên của UML cho phép mọi người trao đổi thiết kế với nhau rõ ràng, truyền đạt được bản chất của thiết kế, kể cả việc sao chép và ánh xạ lại các chức năng cho từng giải pháp phần mềm của họ. Tuy nhiên mọi người nhận thức rằng, việc mô hình hóa hệ thống thì tốt hơn là mô hình hóa phần mềm, vì vậy sẽ tốt hơn khi sử dụng một ngôn ngữ mô hình thống nhất là UML. Phiên bản UML 1.x và các phiên bản trước được thiết kế như là một ngôn ngữ thống nhất hướng con người. Khi việc sử dụng rộng rãi và chia sẽ giữa các hệ thống máy, người ta nhận thấy rằng UML 1.x chưa đủ dễ hiểu giúp máy hiểu được. Phiên bản UML 1.5 ra đời nhằm khắc phục vấn đề trên. Tuy nhiên nó trở nên nặng nề và phức tạp, cũng như khó mở rộng. Một lần nữa mọi người lại tái thiết kế UML. Các nhà thiết kế UML 2.0 đã rất thận trọng để đảm bảo rằng UML 2.0 quen thuộc như UML 1.0. Nhiều ký hiệu và biểu đồ từ UML 1.0 đã được giữ lại và phát triển. Tuy nhiên, vài biểu đồ mới được giới thiệu để mở rộng khả năng của UML 2.0 Ngày hôm nay, với phiên bản 2.0, UML đã tự tin đối mặt với các thách thức về việc mô hình hóa phần mềm cũng như hệ thống. Những quy ước, các phương pháp khác nhau về thiết kế phần mềm từ nhiều năm trước đã phát triển thành một ngôn ngữ mô hình thống nhất. UML đã sẵn sàng và phù hợp để trở thành một ngôn ngữ tiêu chuẩn trong việc thiết kế hệ thống và phần mềm. Bảng 1-1 sau. Mô tả những thay đổi từ UML 1.0 sang UML 2.0 1.3 Các mô hình và biểu đồ Những người mới học UML thường tập trung vào các loại biểu đồ khác nhau để mô hình hóa hệ thống của họ. Thật dễ dàng nhận thấy các biểu đồ chính là mô hình hóa hệ thống. Tuy nhiên đây là sai lầm thường mắc phải khi bạn sử dụng UML với một công cụ UML và một tập hợp các biểu đồ. Nhưng mô hình hóa UML không chỉ nói về biểu đồ, nó nắm bắt hệ thống của bạn như là một mô hình. Và biểu đồ chỉ là một cửa sổ trong mô hình đó. Một biểu đồ cụ thể sẽ thể hiện một khía cạnh của mô hình nhưng không phải là tất cả. Điều này có nghĩa là, vì bạn không muốn một biểu đồ thể hiện tất cả mọi thứ, nên phải chia nhỏ nội dung trong mô hình của bạn ra nhiều biểu đồ khác nhau. Tuy nhiên, không phải mọi thứ trong mô hình đều phải xuất hiện trên 1 biểu đồ nào đó. Điều này có nghĩa là gì? Vâng, việc đầu tiên phải hiểu là mô hình của bạn đang ở bên cạnh các công cụ mô hình hóa và biểu đồ, chúng là tập hợp của nhiều phần tử. Các phần tử này có thể là một use case, một lớp, một hành động, hay một phần khởi tạo nào đó mà UML hỗ trợ. Tập hợp của tất cả các phần tử này sẽ mô tả lại hệ thống của bạn, bao gồm cả việc chúng kết nối với nhau như thế nào.. để tạo nên một mô hình. Tuy nhiên ngoài việc tạo ra một tập hợp các phần tử, cùng với việc xuất hiện của biểu đồ, sẽ giúp bạn hiểu rõ ràng về cách tương tác của hệ thống. Vì vậy lần tới bạn sử dụng UML, hãy nhớ rằng, bạn phải tạo biểu đồ, tạo các phần tử… và chúng chính là những phần nhỏ để tạo nên một mô hình. 1. 4 Sử dụng UML ra sao? UML có thể được sử dụng ít hay nhiều tùy bạn thích. Martin Fowler mô tả ba cách mà mọi người thường có xu hướng khi sử dụng UML. UML như một bản phác thảo: Sử dụng UML như một bản phác thảo ngắn gọn để truyền đạt những điểm chính yếu. Chúng giống như bản thảo được viết lên bảng đen, dùng xong xóa đi UML như một kế hoạch chi tiết: Cung cấp một bản đặc tả chi tiết về hệ thống với các biểu đồ UML. Những biểu đồ này được công cụ UML tạo ra và không chỉ dùng một lần. Phương pháp này thường gắn liền với việc phát triển hệ thống phần mềm, để đảm bảo rằng biểu đồ luôn đồng bộ với code. UML như là một ngôn ngữ lập trình: Từ một mô hình UML, sẽ trực tiếp sinh ra code. Điều này có nghĩa là mọi khía cạnh của hệ thống đều được mô hình hóa. Về mặt lý thuyết bạn có thể giữ mô hình của mình lâu bao nhiêu tùy thích và sử dụng việc tự sinh code khi chuyển đổi qua một môi trường mới Nguồn: haihth.wordpress.com