Pages

7 thg 6, 2010

CĂN BẢN UML

Quay lại về cuối thế kỷ hai mươi --

Chính xác vào năm 1997-- Object Management Group (OMG-Nhóm quản lý đối tượng) đã phát hành bản Unified Modeling Language (UML). Một trong những mục đích của UML là cung cấp cho cộng đồng phát triển một ngôn ngữ thiết kế phổ biến và ổn định, ngôn ngữ này có thể được dùng để phát triển và xây dựng các ứng dụng máy tính. UML đưa ra một ký hiệu mô hình hóa chuẩn thống nhất mà các chuyên gia công nghệ thông tin (CNTT) muốn có trong nhiều năm. Khi sử dụng UML, các chuyên gia CNTT bây giờ đã có thể đọc và phổ biến cấu trúc hệ thống và các kế hoạch thiết kế -- giống như các công nhân xây dựng đang làm trong nhiều năm qua với các kế hoạch chi tiết về các tòa nhà.

Bây giờ là thế kỷ hai mốt -- chính xác là năm 2003-- và UML đã nâng cao sức mạnh trong chuyên ngành của chúng ta. Trên 75% các bản tóm tắt mà tôi thấy, có một điểm nhấn yêu cầu kiến thức về UML. Tuy nhiên, sau khi nói chuyện với đa số các ứng viên cho công việc này, một điều trở nên rõ ràng là họ không thực sự biết UML. Thông thường, hoặc là họ đang sử dụng nó như là một từ thông dụng hoặc họ đã có một phần tiếp xúc với UML. Sự thiếu hiểu biết này đã thôi thúc tôi viết bài giới thiệu vắn tắt này về UML, tập trung vào các sơ đồ cơ bản được sử dụng trong việc mô hình hóa trực quan. Khi bạn đọc xong bạn sẽ không có đủ kiến thức để đặt UML vào tổng quan của bạn, nhưng sẽ có một điểm khởi đầu để nghiên cứu sâu hơn vào ngôn ngữ này.

Một chút nền tảng

Như tôi đã đề cập, UML có nghĩa là một ngôn ngữ thống nhất cho phép các chuyên gia CNTT mô hình hóa các ứng dụng máy tính. Các tác giả chính là Jim Rumbaugh, Ivar Jacobson, và Grady Booch, những người ban đầu đã có các phương pháp cạnh tranh riêng của mình (OMT, OOSE và Booch). Cuối cùng, họ đã tham gia lực lượng và dẫn đến một chuẩn mở. (Âm thanh quen thuộc quá? Một hiện tượng tương tự đã sinh ra J2EE, SOAP và Linux). Một lý do mà UML đã trở thành một ngôn ngữ mô hình hóa chuẩn là tính độc lập của ngôn ngữ lập trình. (Các công cụ mô hình hóa UML của IBM Rational được sử dụng rộng rãi trong các cửa hàng J2EE, cũng như trong các cửa hàng .NET). Ngoài ra, bộ kí hiệu UML là một ngôn ngữ chứ không phải là một phương pháp luận. Điều này là quan trọng, bởi vì một ngôn ngữ, trái với một phương pháp luận, có thể dễ dàng phù hợp với phương diện đạo đức kinh doanh của công ty bất kỳ mà không cần thay đổi.

Do UML không phải là một phương pháp luận, nó không yêu cầu bất kỳ sản phẩm làm ra chính thức nào (tức là, "các tạo phẩm" trong từ ngữ đặc biệt của IBM Rational Unified Process®). Tuy nhiên, nó cung cấp một vài kiểu sơ đồ, khi được sử dụng trong một phương pháp cụ thể, các sơ đồ đó làm tăng sự dễ hiểu cho một ứng dụng đang được phát triển. Có nhiều thứ với UML hơn các sơ đồ này, nhưng với mục đích của tôi ở đây, các sơ đồ cung cấp sự mở đầu tốt cho ngôn ngữ và các nguyên lý phía sau việc sử dụng của nó. Bằng cách đặt các sơ đồ UML chuẩn trong các sản phẩm tạo ra của phương pháp luận của bạn, với những người thành thạo, UML bạn làm cho nó trở nên dễ nhập vào dự án của bạn hơn và nhanh chóng biến thành sản phẩm. Các sơ đồ UML chuẩn, có ích nhất là: sơ đồ ca sử dụng, sơ đồ lớp, sơ đồ trình tự, sơ đồ trạng thái (statechart), sơ đồ hoạt động, sơ đồ thành phần và sơ đồ triển khai.

Để đi sâu vào nhiều chi tiết về từng kiểu sơ đồ sẽ vượt ra ngoài phạm vi của bài viết giới thiệu này. Thay vào đó, tôi sẽ cung cấp cho bạn với đủ thông tin cho một sự hiểu biết chung về từng sơ đồ và sau đó cung cấp nhiều chi tiết hơn trong các bài viết sau.


Sơ đồ ca sử dụng

Một ca sử dụng minh họa một đơn vị chức năng được hệ thống cung cấp. Mục đích chính của việc sử dụng sơ đồ ca sử dụng là giúp các nhóm phát triển hình dung ra các yêu cầu chức năng của một hệ thống, bao gồm mối quan hệ của "các vai" (con người, người sẽ tương tác với hệ thống) với các quy trình cần thiết, cũng như các mối quan hệ trong số các ca sử dụng khác nhau. Các sơ đồ ca sử dụng nói chung cho thấy các nhóm các ca sử dụng -- hoặc tất cả các ca sử dụng cho hệ thống hoàn chỉnh, hoặc sự đột phá của một nhóm các ca sử dụng cụ thể với chức năng liên quan (ví dụ, tất cả các ca sử dụng có liên quan đến quản trị an ninh). Để cho thấy ca sử dụng trên một sơ đồ ca sử dụng, bạn vẽ hình bầu dục ở giữa sơ đồ và đặt tên ca sử dụng ở trung tâm, hoặc bên dưới, hình bầu dục. Để vẽ một vai (chỉ thị một người sử dụng hệ thống) trên một sơ đồ ca sử dụng, bạn vẽ một người dính vào bên trái hay bên phải sơ đồ của bạn (và chỉ trong trường hợp bạn đang muốn biết, một số người vẽ người đi kèm đẹp hơn những người khác). Sử dụng các đường đơn giản để miêu tả các mối quan hệ giữa vai và các ca sử dụng, như trong Hình 1.

Sơ đồ trường hợp sử dụng

Hình 1: Sơ đồ ca sử dụng mẫu

Sơ đồ ca sử dụng thường được dùng để giao tiếp các hàm cấp cao của hệ thống và quy mô của hệ thống. Bằng cách xem xét sơ đồ ca sử dụng mẫu của chúng ta trong Hình 1, bạn có thể dễ dàng chỉ ra các hàm mà hệ thống ví dụ của chúng ta cung cấp. Hệ thống này cho phép những người quản lý ban nhạc xem qua một báo cáo thống kê bán hàng và báo cáo Billboard 200 (bảng xếp hạng 200 anbum âm nhạc bản chạy nhất) với các đĩa CD của ban nhạc. Nó cũng cho phép xem một báo cáo thống kê bán hàng và báo cáo Billboard 200 cho riêng một đĩa CD. Sơ đồ này cũng cho chúng ta biết hệ thống của chúng ta cung cấp các báo cáo Billboard từ một hệ thống bên ngoài được gọi là Dịch vụ báo cáo Billboard (Billboard Reporting Service).

Ngoài ra, sự vắng mặt của các ca sử dụng trong sơ đồ này cho thấy những gì hệ thống không làm được. Ví dụ, nó không cung cấp cách cho phép người quản lý ban nhạc nghe các bài hát từ các album khác nhau trên bảng xếp hạng Billboard 200 -- tức là chúng ta thấy không có tham chiếu đến một ca sử dụng được gọi là Nghe các bài hát từ Billboard 200. Sự thiếu vắng này không phải là một vấn đề nhỏ. Với các sự mô tả ca sử dụng rõ ràng và đơn giản được cung cấp trên sơ đồ như vậy, một nhà tài trợ cho dự án có thể dễ dàng nhìn thấy chức năng cần thiết nào có hay không có trong hệ thống.


Sơ đồ lớp

Sơ đồ lớp cho thấy các thực thể khác nhau (người, các chủ đề và dữ liệu) liên quan với nhau như thế nào; nói cách khác, nó cho thấy các cấu trúc tĩnh của hệ thống. Một sơ đồ lớp có thể được sử dụng để hiển thị các lớp hợp lý, chúng thường là các chủ đề khác nhau mà các doanh nhân trong một tổ chức hay bàn về chúng -- các ban nhạc rock, các đĩa CD, phát thanh hoặc các khoản vay, thế chấp nhà, các khoản vay mua xe và lãi suất. Các sơ đồ lớp cũng có thể được sử dụng để hiển thị các lớp thực hiện, chúng là những lớp mà các lập trình viên thường hay xử lý. Một sơ đồ lớp thực hiện có thể sẽ cho thấy một số các lớp giống như sơ đồ các lớp hợp lý. Lớp thực hiện sẽ không được vẽ với các thuộc tính như nhau, tuy nhiên, vì nó hầu như sẽ có khả năng có các tham khảo đến những thứ như các Vectơ và HashMaps.

Một lớp được mô tả trong sơ đồ lớp như là một hình chữ nhật với ba phần nằm ngang, như trong Hình 2. Phần phía trên chỉ ra tên của lớp; phần giữa có chứa các thuộc tính của lớp; và phần dưới chứa hoạt động của lớp (hay "các phương thức").

Đối tượng lớp mẫu trong một sơ đồ lớp

Hình 2: Đối tượng lớp mẫu trong một sơ đồ lớp

Theo kinh nghiệm của tôi, hầu như tất cả các nhà phát triển đều biết sơ đồ này là gì, nhưng tôi thấy rằng hầu hết các lập trình viên vẽ các đường quan hệ không đúng. Đối với một sơ đồ lớp như trong Hình 3, bạn nên vẽ mối quan hệ kế thừa 1 bằng cách sử dụng một đường có một mũi tên ở đầu chỉ tới siêu lớp và mũi tên nên là một tam giác hoàn chỉnh. Một mối quan hệ liên kết nên là một đường nét liền nếu cả hai lớp nhận ra được nhau và là một đường có một mũi tên hở nếu liên kết đó chỉ được một trong các lớp này biết đến.

Một sơ đồ lớp hoàn chỉnh

Một sơ đồ lớp hoàn chỉnh, bao gồm đối tượng lớp được hiển thị trong Hình 2
(nhấn vào đây để phóng to)

Trong Hình 3, chúng ta thấy cả hai mối quan hệ kế thừa và hai mối quan hệ liên kết. Lớp CDSalesReport kế thừa từ các lớp Report (Báo cáo). Một lớp CDSalesReport được liên kết với một đĩa CD, nhưng lớp CD không biết gì về lớp CDSalesReport. Cả hai đĩa CD và các lớp Band (Ban nhạc) đều biết về nhau và cả hai lớp có thể được kết hợp với một hoặc nhiều lớp với nhau.

Một sơ đồ lớp có thể tích hợp thêm nhiều khái niệm, mà chúng ta sẽ trình bày sau trong loạt bài này.


Sơ đồ trình tự

Sơ đồ trình tự (sequence) hiển thị một dòng chi tiết cho một ca sử dụng cụ thể hoặc thậm chí chỉ là một phần của một ca sử dụng cụ thể. Hầu như chúng tự giải thích; chúng hiển thị các lời gọi giữa các đối tượng khác nhau theo trình tự của chúng và có thể hiển thị, ở một mức độ chi tiết, các lời gọi khác với các đối tượng khác.

Một sơ đồ trình tự có hai chiều: Chiều dọc cho thấy trình tự của thông báo/các lời gọi theo thứ tự thời gian mà chúng xảy ra; chiều ngang thể hiện các cá thể đối tượng mà các thông báo được gửi tới chúng.

Một sơ đồ trình tự vẽ rất đơn giản. Ngang trên đầu sơ đồ của bạn, xác định các cá thể lớp (đối tượng) bằng cách đặt mỗi cá thể lớp trong hộp (xem Hình 4). Trong hộp này, đặt tên cá thể lớp và tên lớp được ngăn cách bằng một khoảng trống/ dấu hai chấm/ khoảng trống " : " (ví dụ, myReportGenerator : ReportGenerator). Nếu một cá thể lớp gửi một thông báo đến một cá thể lớp khác, vẽ một đường với một mũi tên hở trỏ đến cá thể lớp nhận; đặt tên của thông báo/ phương thức trên đường vẽ đó. Tùy chọn, với các thông báo quan trọng, bạn có thể vẽ một đường chấm chấm có một mũi tên chỉ ngược về cá thể lớp ban đầu; ghi nhãn giá trị trả về trên đường chấm chấm đó. Riêng tôi luôn muốn có đường giá trị trả về vì tôi muốn tìm các chi tiết phụ làm cho nó dễ đọc hơn.

Đọc một sơ đồ trình tự rất đơn giản. Bắt đầu tại góc trên bên trái với cá thể lớp "trình điều khiển" bắt đầu trình tự. Sau đó đi theo mỗi thông báo dưới sơ đồ. Hãy nhớ rằng: Mặc dù sơ đồ trình tự ví dụ trong Hình 4 cho thấy một thông báo trả về cho mỗi thông báo đã gửi, đây là tùy chọn.

Một sơ đồ trình tự mẫu

Hình 4: Một sơ đồ trình tự mẫu
(nhấn vào đây để phóng to)

Bằng cách đọc sơ đồ trình tự mẫu của chúng ta trong Hình 4, bạn có thể thấy cách tạo một Báo cáo bán đĩa CD (CD Sales Report). Đối tượng aServlet là một trình điều khiển ví dụ của chúng ta. aServlet gửi một thông báo đến cá thể lớp ReportGenerator có tên là gen. Thông báo này được ghi nhãn là generateCDSalesReport, nó có nghĩa là đối tượng ReportGenerator triển khai thực hiện trình xử lý thông báo này. Trên cơ sở kiểm tra chặt chẽ hơn, nhãn thông báo generateCDSalesReport có cdId trong ngoặc đơn, có nghĩa là aServlet đang chuyển cùng với thông báo một biến có tên là cdId. Khi cá thể gen nhận được một thông báo generateCDSalesReport, rồi nó thực hiện các lời gọi tiếp theo đến lớp CDSalesReport và cá thể hiện tại của một CDSalesReport gọi là aCDReport được trả về. Sau đó cá thể gen thực hiện các lời gọi đến cá thể aCDReport được trả về, chuyển qua nó các tham số trên mỗi lời gọi thông báo. Vào cuối trình tự, cá thể gen trả về một aCDReport đến người gọi aServlet của nó.

Xin lưu ý: Sơ đồ trình tự trong Hình 4 được cho là quá chi tiết với một sơ đồ trình tự điển hình. Tuy nhiên, tôi tin rằng nó đủ đơn giản để hiểu và nó cho thấy các lời gọi lồng nhau được vẽ như thế nào. Ngoài ra, với các nhà phát triển mới bắt đầu, đôi khi cần thiết phá vỡ các trình tự theo mức rõ ràng này để giúp họ hiểu những gì họ phải làm.


Sơ đồ trạng thái (statechart)

Sơ đồ statechart (đồ thị trạng thái) mô hình hóa các trạng thái khác nhau mà một lớp có thể có và lớp đó chuyển từ trạng thái này sang trạng thái khác như thế nào. Có thể lập luận rằng mỗi lớp có một trạng thái, nhưng mỗi lớp đó không nên có một sơ đồ trạng thái. Chỉ có các lớp có trạng thái "hay ho - interesting"-- đó là, các lớp có ba hay nhiều trạng thái có tiềm năng trong quá trình hoạt động của hệ thống -- nên được mô hình hóa.

Như trong hình 5, bộ ký hiệu của sơ đồ trạng thái có năm yếu tố cơ bản: điểm xuất phát đầu tiên, được vẽ bằng cách sử dụng một vòng tròn nét liền; một quá trình chuyển đổi giữa các trạng thái, được vẽ bằng cách sử dụng một đường có một mũi tên hở; một trạng thái, được vẽ bằng cách sử dụng một hình chữ nhật với các góc tròn; một điểm quyết định, được vẽ như một vòng tròn mở; và một hoặc nhiều điểm kết thúc, được vẽ bằng cách sử dụng một vòng tròn có một vòng tròn nét liền bên trong nó. Để vẽ một sơ đồ trạng thái, hãy bắt đầu với một điểm xuất phát và một đường chuyển tiếp chỉ tới trạng thái ban đầu của lớp. Vẽ các trạng thái của chúng ở bất cứ nơi nào trên sơ đồ và sau đó chỉ cần kết nối chúng bằng cách sử dụng các đường chuyển tiếp trạng thái.

Sơ đồ trạng thái

Sơ đồ trạng thái hiển thị các trạng thái khác nhau mà các lớp chuyển qua trong một hệ thống chức năng
nhấn vào đây để phóng to)

Sơ đồ trạng thái ví dụ trong Hình 5 cho thấy một số thông tin tiềm năng mà chúng có thể giao tiếp. Ví dụ, bạn có thể cho rằng việc xử lý cho vay bắt đầu trong trạng thái Loan Application (Ứng dụng cho vay). Khi quá trình chấp thuận đầu tiên được thực hiện, tùy thuộc vào kết quả, bạn di chuyển đến hoặc là trạng thái Loan Pre-approved (Cho vay được chấp thuận lần đầu tiên) hoặc trạng thái Loan Rejected (Từ chối cho vay). Quyết định này, được thực hiện trong quá trình chuyển tiếp, được hiển thị bằng một điểm quyết định, tức các vòng tròn rỗng trong đường chuyển tiếp. Bằng cách xem ví dụ, một người có thể nói rằng một khoản vay có thể không xuất phát từ trạng thái Loan Pre-Approved đến trạng thái Loan (Cho vay) trong trạng thái Maintenance (Bảo trì) mà không đi qua trạng thái Loan Closing (Kết thúc cho vay). Ngoài ra, bằng cách xem sơ đồ ví dụ của chúng ta, một người có thể cho rằng tất cả các khoản vay sẽ kết thúc trong hoặc trạng thái Loan Rejected hoặc Loan trong trạng thái Maintenance.


Sơ đồ hoạt động

Sơ đồ hoạt động hiển thị luồng kiểm soát theo thủ tục giữa hai hay nhiều đối tượng lớp khi xử lý một hoạt động. Các sơ đồ hoạt động có thể được sử dụng để mô hình hóa quy trình kinh doanh cao cấp hơn ở mức đơn vị kinh doanh, hoặc để mô hình hóa các hành động bên trong mức thấp. Theo kinh nghiệm của tôi, các sơ đồ hoạt động tốt nhất được sử dụng để mô hình hóa quy trình cao cấp hơn, chẳng hạn công ty hiện đang kinh doanh như thế nào, hoặc muốn tiến hành kinh doanh như thế nào. Điều này là do các sơ đồ hoạt động có vẻ "ít kỹ thuật" hơn so với các sơ đồ trình tự và những người thích kinh doanh có xu hướng hiểu chúng nhanh hơn.

Một bộ ký hiệu hoạt động tương tự như các ký hiệu đã sử dụng trong một sơ đồ trạng thái. Giống như một sơ đồ trạng thái, sơ đồ hoạt động bắt đầu bằng một vòng tròn nét liền kết nối tới hoạt động ban đầu. Hoạt động này được mô hình hóa bằng cách vẽ một hình chữ nhật có các cạnh tròn, kèm theo tên của hoạt động. Các hoạt động có thể được kết nối với các hoạt động khác thông qua các đường chuyển tiếp, hoặc đến các điểm quyết định có kết nối tới các hoạt động khác được các điều kiện của điểm quyết định bảo vệ. Các hoạt động, chấm dứt quá trình được mô hình hóa, được kết nối với một điểm kết thúc (giống như trong một sơ đồ trạng thái). Tùy chọn, các hoạt động có thể được nhóm lại thành các làn đường, chúng được sử dụng để chỉ ra đối tượng thực sự thực hiện các hoạt động, như trong Hình 6.

Sơ đồ hoạt động, với hai làn đường

Hình 6: Sơ đồ hoạt động, với hai làn đường để chỉ thị việc kiểm soát hoạt động của hai đối tượng: người quản lý ban nhạc và công cụ lập báo cáo

Trong sơ đồ hoạt động ví dụ của chúng ta, chúng ta có hai làn đường vì chúng ta có hai đối tượng kiểm soát các hoạt động riêng biệt: một người quản lý ban nhạc và một công cụ lập báo cáo. Quá trình này bắt đầu với việc người quản lý ban nhạc chọn xem báo cáo bán hàng của một trong những ban nhạc của mình. Công cụ lập báo cáo sau đó lấy ra và hiển thị tất cả các ban nhạc mà người đó quản lý và yêu cầu anh ta phải chọn một ban nhạc. Sau khi người quản lý ban nhạc chọn một ban nhạc, công cụ lập báo cáo lấy ra thông tin bán hàng và hiển thị bản báo cáo bán hàng. Sơ đồ hoạt động cho thấy rằng việc hiển thị báo cáo là bước cuối cùng trong quá trình này.



Sơ đồ thành phần

Một sơ đồ thành phần cung cấp một khung nhìn vật lý của hệ thống. Mục đích của nó là hiển thị các phụ thuộc mà phần mềm có trên các thành phần phần mềm khác (ví dụ, các thư viện phần mềm) trong hệ thống. Sơ đồ này có thể được hiển thị ở mức rất cao, chỉ với các thành phần có độ chi tiết lớn hoặc nó có thể được hiển thị tại mức gói.2

Mô hình hóa một sơ đồ thành phần tốt nhất được mô tả thông qua một ví dụ. Hình 7 cho thấy bốn thành phần: Reporting Tool (Công cụ lập báo cáo), Billboard Service (Dịch vụ Billboard), Servlet 2.2 API và JDBC API. Các đường mũi tên từ thành phần Reporting Tool đến các thành phần Billboard Service, Servlet 2.2 API, JDBC API muốn nói rằng Reporting Tool phụ thuộc vào ba thành phần đó.

sơ đồ thành phần

Hình 7: Một sơ đồ thành phần cho thấy các sự phụ thuộc lẫn nhau của các thành phần phần mềm khác nhau mà hệ thống đó bao gồm


Sơ đồ triển khai

Sơ đồ triển khai cho thấy cách một hệ thống sẽ được triển khai cụ thể trong môi trường phần cứng. Mục đích của nó là hiển thị các thành phần khác nhau của hệ thống cụ thể sẽ chạy ở đâu và làm thế nào để chúng giao tiếp với nhau. Từ sơ đồ mô hình hóa thời gian chạy cụ thể, nhân viên sản xuất của hệ thống sẽ sử dụng sơ đồ này nhiều hơn.

Ký hiệu trong một sơ đồ triển khai bao gồm các yếu tố ký hiệu được sử dụng trong một sơ đồ thành phần, với một vài bổ sung, bao gồm khái niệm về một nút. Một nút biểu diễn hoặc một nút máy vật lý hay một nút máy ảo (ví dụ như, một nút máy tính lớn). Để mô hình hóa một nút, chỉ cần vẽ một hình khối ba chiều với tên của nút đó ở phía trên của khối này. Sử dụng quy ước đặt tên được sử dụng trong sơ đồ trình tự: [tên cá thể]: [kiểu cá thể] (ví dụ, "w3reporting.myco.com : Application Server").

Sơ đồ triển khai

Hình 8: Sơ đồ triển khai. Do thành phần Reporting Tool được vẽ bên trong của IBM WebSphere, mà IBM WebSphere lần lượt được vẽ bên trong của nút w3.reporting.myco.com, nên chúng ta biết rằng những người dùng sẽ truy cập Reporting Tool thông qua một trình duyệt đang chạy trên máy cục bộ của họ và kết nối thông qua HTTP trên mạng nội bộ của công ty họ.
(nhấn vào đây để phóng to)

Sơ đồ triển khai tại Hình 8 cho thấy rằng những người dùng truy cập vào Reporting Tool bằng cách sử dụng một trình duyệt đang chạy trên máy cục bộ của họ và kết nối qua HTTP trên mạng nội bộ của công ty họ tới Reporting Tool. Công cụ này cụ thể chạy trên các máy chủ ứng dụng có tên w3reporting.myco.com. Sơ đồ đã thể hiện thành phần Reporting Tool được vẽ bên trong IBM WebSphere, IBM WebSphere lần lượt được vẽ bên trong của nút w3.reporting.myco.com. Reporting Tool kết nối tới cơ sở dữ liệu báo cáo của mình bằng cách sử dụng ngôn ngữ Java với giao diện JDBC của IBM DB2, sau đó giao diện này giao tiếp với cơ sở dữ liệu DB2 thực tế đang chạy trên máy chủ đặt tên là db1.myco.com bằng cách sử dụng giao tiếp bản địa DB2. Thêm vào việc trao đổi với cơ sở dữ liệu báo cáo, thành phần Report Tool truyền dẫn SOAP trên HTTPS tới Billboard Service.


Kết luận

Mặc dù bài viết này chỉ cung cấp một sự giới thiệu ngắn gọn về Unified Modeling Language (Ngôn ngữ mô hình thống nhất), tôi khuyến khích bạn bắt đầu áp dụng các thông tin mà bạn đã học được ở đây cho các dự án riêng của mình và để nghiên cứu kỹ hơn về UML. Có rất nhiều công cụ phần mềm giúp bạn tích hợp các sơ đồ UML vào trong quá trình phát triển phần mềm của bạn, nhưng ngay cả khi không có công cụ tự động hóa, bạn có thể sử dụng các dụng cụ để viết trên bảng hoặc giấy và bút chì để vẽ các sơ đồ UML của bạn và vẫn đạt được các lợi ích.


Ghi chú

1 Để biết thêm thông tin về các nguyên tắc thừa kế và hướng đối tượng khác, xem http://java.sun.com/docs/books/tutorial/java/concepts/inheritance.html

2 Mức gói thành phần cụm từ là một cách trung gian về ngôn ngữ lập trình đề cập đến các mức thùng chứa lớp như các vùng tên của .NET (ví dụ, System.Web.UI) hoặc các gói của Java (ví dụ, java.util).


Tài nguyên

http://www.uml.org/ -- Trang Web UML chính thức.
http://www.rational.com/uml/resources/documentation/index.jsp --Cung cấp một số phiên bản khác nhau của đặc tả UML thực sự.
http://www-140.ibm.com/developerworks/rational/products/rose --Thông tin về IBM Rational Rose®, một công cụ mô hình hóa UML thương mại.
http://www-140.ibm.com/developerworks/rational/products/xde--Thông tin về IBM Rational XDE®, một công cụ mô hình hóa UML thương mại được tích hợp với nền tảng phát triển Eclipse của IBM.
http://argouml.tigris.org/ --Thông tin về Argo UML, một công cụ mô hình hóa UML mã nguồn mở được xây dựng trong Java.
http://uml.sourceforge.net/index.php -- Thông tin về Umbrello UML Modeller, một công cụ mô hình hóa UML mã nguồn mở UML cho KDE.

0 nhận xét:

Đăng nhận xét

Powered By Blogger