Tích hợp rational software architect với rational data architect

Nội dung text: Tích hợp rational software architect với rational data architect

1. Tài liệu Đề tài: Tích hợp Rational Software Architect với Rational Data Architect
2. Tích hợp Rational Software Architect với Rational Data Architect Làm cho mô hình ứng dụng và mô hình dữ liệu của bạn làm việc với nhau Daniel T. Chang, Kỹ sư phần mềm, IBM Tóm tắt: Phát triển phần mềm hướng mô hình (model-driven) thường bắt đầu bằng việc hoặc mô hình hóa ứng dụng hoặc mô hình hóa dữ liệu. Tuy nhiên, mô hình hóa ứng dụng và mô hình hóa dữ liệu liên quan chặt chẽ và bổ sung cho nhau. IBM đã nhận thức được tầm quan trọng của việc tích hợp mô hình hóa ứng dụng với mô hình hóa dữ liệu trong việc phát triển phần mềm hướng mô hình và đã phát triển các phép chuyển đổi từ ngôn ngữ mô hình hóa thống nhất (Unified Modeling Language -UML) sang mô hình dữ liệu lôgic (Logical Data Model -LDM) và từ LDM sang UML. Các phép chuyển đổi này tích hợp việc mô hình hóa ứng dụng bằng cách sử dụng sản phẩm Rational Software Architect (RSA) và việc mô hình hóa dữ liệu bằng cách sử dụng Rational Data Architect (RDA). Bài viết này cung cấp cho bạn một tổng quan nhanh về RSA và RDA, phác ra các bước thực hiện ở mức cao trong ba kịch bản về tích hợp giữa RSA và RDA và thảo luận về các phép chuyển đổi UML-LDM và LDM-UML và lược thảo mô hình dữ liệu lôgic của UML. [17 tháng Tư 2009: Lưu ý bổ sung về việc đổi tên sản phẩm từ Rational Data Architect thành InfoSphere Data Architect – Ban biên tập] Cách tiếp cận hướng mô hình đang được sử dụng rộng rãi để phát triển phần mềm. Trong việc phát triển phần mềm hướng mô hình, thì hoặc mô hình hóa ứng dụng hoặc mô hình hóa dữ liệu thường được sử dụng làm điểm khởi đầu. Tuy nhiên, mô hình hóa ứng dụng và mô hình hóa dữ liệu rất giống với nhau. Mô hình hóa ứng dụng nắm bắt các thông tin nghiệp vụ then chốt dưới dạng các lớp và các quan hệ kết hợp ở dạng mô hình lớp bằng ngôn ngữ UML. Các mô hình lớp sau đó có thể được sử dụng làm cơ sở cho việc dẫn xuất ra các mô hình dữ liệu lôgic để mô hình hóa dữ liệu. Mặt khác, mô hình hóa dữ liệu nắm bắt các thực thể nghiệp vụ, các
3. mối quan hệ của chúng và các ràng buộc trong các mô hình dữ liệu lôgic (LDM), mà sau đó chúng có thể được sử dụng để dẫn xuất ra các mô hình lớp dành cho mô hình hóa ứng dụng. Mô hình dữ liệu lôgic LDM được lập đúng cách có thể cung cấp một biểu diễn duy nhất đúng (single-truth) của các thông tin nghiệp vụ then chốt trong một doanh nghiệp. Nó có thể bao trùm và tồn tại lâu hơn so với nhiều ứng dụng và các nguồn dữ liệu vật lý. Các ngữ nghĩa rõ ràng, chính xác và đầy đủ trong LDM cung cấp một nền tảng hoàn hảo cho các mô hình lớp khi các tổ chức thực hiện nhiệm vụ mô hình hóa ứng dụng. Cho dù bắt đầu từ mô hình hóa ứng dụng hay mô hình hóa dữ liệu, khi các hình thức mô hình hóa khác nhau ấy được kết hợp một cách chính thống, thì sức mạnh của việc phát triển phần mềm hướng mô hình được bộc lộ bởi vì chúng ta đã: • Đạt được khả năng liên tác của mô hình xuyên suốt doanh nghiệp và xuyên suốt các tầng kiến trúc doanh nghiệp, • Tạo ra các mô hình thông tin có thể sử dụng lại được, chúng rất có ích cho nhiều ứng dụng, • Tách rời ngữ nghĩa dữ liệu với các triển khai thực hiện về mặt vật lý, và • Cho phép tách biệt các mối quan tâm giữa nhà mô hình hóa ứng dụng và nhà mô hình hóa dữ liệu. Thay đổi tên sản phẩm Ngày 16 tháng 12 năm 2008, công ty IBM ra thông báo rằng kể từ phiên bản 7.5.1, sản phẩm Rational Data Architect được đổi tên thành InfoSphere Data Architect để nâng cao vai trò của sản phẩm trong bộ công cụ InfoSphere Foundation.
4. IBM là công ty đi đầu trong việc cung cấp các công cụ mô hình hóa ứng dụng và gần đây đã bổ sung các công cụ mô hình hóa dữ liệu. Người sử dụng có thể mô hình hóa các ứng dụng bằng sản phẩm Rational Software Architecture (RSA) và mô hình hóa dữ liệu bằng sản phẩm Rational Data Architect (RDA). IBM nhận thức được tầm quan trọng của việc tích hợp mô hình hóa ứng dụng và mô hình hóa dữ liệu vào việc phát triển phần mềm hướng mô hình và đã phát triển phép chuyển đổi từ UML sang LDM và từ LDM sang UML để liên kết các công cụ này lại với nhau. Các phép chuyển đổi từ UML sang LDM là một đặc tính tùy chọn của RSA V7, và phép chuyển đổi từ LDM sang UML là một đặc tính tùy chọn của RDA V7. Tài liệu hướng dẫn trực tuyến về mỗi sản phẩm sẽ chi tiết hóa thủ tục theo từng bước để cài đặt và sử dụng mỗi phép chuyển đổi tương ứng và cũng bao gồm các thông tin về ánh xạ đối tượng. Bài viết này trước tiên cung cấp một tổng quan nhanh về RSA và RDA, sau đó phác ra các bước ở mức cao về ba kịch bản tích hợp của RSA-RDA. Đối với kịch bản từ UML chuyển đổi sang LDM (từ trên xuống) và đối với kịch bản chuyển đổi từ LDM sang UML (từ dưới lên), nó cung cấp thêm các khuyến nghị khi nào thì các tổ chức nên xem xét việc sử dụng mỗi kịch bản đó. Bài viết này tiếp tục thảo luận về việc mô hình hóa ứng dụng trong RSA, mô hình hóa dữ liệu trong RDA và các phép chuyển đổi từ UML sang LDM (từ trên xuống) và từ LDM sang UML (từ dưới lên). Bài viết cũng bàn về các lược khai của mô hình dữ liệu lôgic, lược khai này cho phép việc mô hình hóa dữ liệu trong RSA và tăng cường các phép chuyển đổi từ UML sang LDM và từ LDM sang UML. Xin lưu ý rằng khi phép chuyển đổi từ UML sang LDM và phép chuyển đổi từ LDM sang UML là cốt lõi của tích hợp RSA và RDA, thì có những khía cạnh quan trọng khác của việc tích hợp RSA và RDA đáng được nêu lên như sau: • Cài đặt chung và chia sẻ chung hệ shell để dễ triển khai và sử dụng
5. • Kho lưu trữ mô hình chung, sử dụng lệnh ClearCase • Bộ công cụ phát triển hướng mô hình chung (Mô hình EMF, khung công tác chuyển đổi, khả năng mở rộng, vv ) Việc thảo luận về các chủ đề này nằm ngoài phạm vi của bài viết này. Sản phẩm Rational Software Architect Sản phẩm Rational Software Architect (RSA) hay Trình kiến trúc phần mềm của Rational, là một công cụ mô hình hóa ứng dụng, cho phép một tổ chức tạo mô hình, phân tích, thiết kế và tạo ra các ứng dụng. Nó thúc đẩy sự phát triển hướng mô hình với ngôn ngữ UML để tạo các ứng dụng có kiến trúc tốt và các dịch vụ. RSA: • Mở rộng Eclipse, môi trường phát triển phần mềm mở và có thể mở rộng được. • Khai thác cái mới nhất trong công nghệ ngôn ngữ mô hình hóa, cho phép mô hình hóa linh hoạt trên nhiều lĩnh vực khác nhau bao gồm UML 2, dùng ký pháp kiểu UML cho Java và nhiều hơn nữa. • Cho phép quản lý linh hoạt các mô hình để phát triển song song và tái cấu trúc về mặt kiến trúc; ví dụ: bạn có thể tách, kết hợp, so sánh và hợp nhất các mô hình và các đoạn mô hình. • Làm dễ dàng quá trình chuyển tiếp giữa kiến trúc và mã hóa với các phép chuyển đổi mô hình-thành-mô hình và mô hình-thành-mã lệnh, bao gồm cả phép chuyển đổi ngược. • Làm dễ dàng hơn cho trải nghiệm chuyển đổi thiết kế-thành-mã lệnh đối với các ứng dụng Java™/J2EE™, dịch vụ Web, SOA và C/C+ +.
6. • Bao gồm tất cả các đặc tính của sản phẩm Rational Application Developer của IBM cho quá trình thiết kế và phát triển tích hợp. Các lớp RSA có thể là bất cứ thứ gì được tạo ra, lắp ráp, tra soát, kiểm thử, sửa đổi, hoặc gia công trong các ứng dụng. Hình 1 dưới đây minh họa một số lớp mẫu và các quan hệ kết hợp của chúng – Invoice (Hoá đơn), InvoiceItem (mục hàng trong hóa đơn), ProductInvoice (hóa đơn sản phẩm) và ServiceInvoice (hóa đơn dịch dụ) của một dự án RSA mẫu có tên là Invoice. Bạn lưu ý rằng có ba loại quan hệ kết hợp khác nhau được thể hiện: cấu thành (hoá đơn - mục hàng), kết tập (chính – phụ) và kết hợp đơn giản (sản phẩm - dịch vụ). Các quan hệ kết hợp này sẽ được thảo luận sau trong bài viết này. Hình 1. Mô hình lớp mẫu trong dự án RSA Invoice Sản phẩm Rational Data Architect Sản phẩm Rational Data Architect (RDA) hay Trình kiến trúc dữ liệu của Rational, là một công cụ thiết kế tích hợp và mô hình hóa dữ liệu cho doanh nghiệp. Nó đơn giản hóa việc thiết kế tích hợp và mô hình hóa dữ liệu, cho phép các kiến trúc sư
7. phát hiện, mô hình hóa, trực quan hóa và liên kết các tài sản dữ liệu đa dạng và phân tán. Khi sử dụng RDA ta có thể: • Tạo các mô hình dữ liệu lôgic và vật lý. • So sánh và đồng bộ hóa các cấu trúc và các phần tử của hai mô hình dữ liệu. • Phân tích các mô hình dữ liệu để hiệu chỉnh và làm cho chúng phù hợp với các tiêu chuẩn của doanh nghiệp. • Phát hiện, khám phá và hiển thị trực quan cấu trúc của các nguồn dữ liệu. • Sử dụng ánh xạ để phát hiện các mối quan hệ tiềm năng và xác định các mối quan hệ giữa các nguồn dữ liệu khác nhau. Hình 2 dưới đây minh họa một mẫu LDM của dự án RDA có tên là Invoice. Bạn lưu ý rằng có ba loại quan hệ: nhận diện (mục hàng-hoá đơn), không nhận diện (phụ – chính) và nhiều -nhiều (dịch vụ-sản phẩm). Bạn cũng nên lưu ý rằng sự thừa kế khóa (key inheritance) xảy ra đối với các quan hệ tổng quát hóa và sự di trú khóa (key migration) xảy ra đối với các quan hệ nhận diện và không nhận diện. Chủ đề này sẽ được thảo luận sau trong bài viết này.
8. Hình 2. Một LDM mẫu trong dự án RDA “Invoice”. Các mô hình dữ liệu lôgic thường bị bỏ qua trong vòng đời phát triển phần mềm, nhưng chúng trở nên ngày càng quan trọng vì nhiều lý do. Các LDM cung cấp một cái nhìn về các thực thể dữ liệu trong một nghiệp vụ hoặc trong một doanh nghiệp mà không phô bày chi tiết triển khai thực hiện; chúng tách ngữ nghĩa dữ liệu khỏi việc triển khai thực hiện và đặc biệt hữu ích khi xử lý các môi trường CNTT ngày càng phức tạp và không đồng nhất hiện nay. Các mô hình lôgic hoặc vật lý khác, chẳng hạn như các mô hình dịch vụ, các mô hình thông điệp, các mô hình lớp và mô hình kho dữ liệu, tất cả đều có thể được truy nguồn từ một LDM chung. Với các công cụ phát triển hướng mô hình hiện đại như Rational Data Architect và Rational Software Architect, người sử dụng thậm chí có thể tạo ra các mô hình cuối luồng (downstream) và triển khai thực hiện vật lý dựa trên LDM. Không phải là cường điệu khi nói rằng LDM là điểm tập trung thông tin của một tổ chức. LDM cho phép doanh nghiệp xem dữ liệu, do đó chúng giúp giảm thiểu dư thừa dữ liệu, cải thiện chất lượng dữ liệu, và tăng tốc độ tích hợp.
9. Về đầu trang Các kịch bản tích hợp Có ba kịch bản chính để tích hợp mô hình hóa ứng dụng và mô hình hóa dữ liệu: từ trên xuống dưới, từ dưới lên trên và gặp nhau ở giữa đường (meet-in-the- middle). Các phần sau của bài viết sẽ mô tả từng kịch bản chi tiết hơn. Ta giả định rằng có hai vai trò CNTT chính đang tham gia vào kịch bản: Nhà mô hình ứng dụng thực hiện mô hình hóa ứng dụng và nhà mô hình dữ liệu thực hiện mô hình hóa dữ liệu. Từ trên xuống dưới: Từ mô hình hóa ứng dụng sang mô hình hóa dữ liệu Trong kịch bản từ trên xuống dưới thì các phần tử mô hình hóa lớp (các lớp, thuộc tính và quan hệ kết hợp) trong RSA được chuyển thành các phần tử mô hình hóa LDM (các thực thể, thuộc tính và các quan hệ) để sử dụng trong RDA. Các bước trong kịch bản này như sau: 1. Nhà mô hình ứng dụng tạo các mô hình ứng dụng trong RSA. Các dữ liệu ứng dụng hay kinh doanh được nắm bắt dưới dạng các mô hình lớp. 2. Nhà mô hình ứng dụng chuyển đổi một phần, hoặc toàn bộ một mô hình lớp thành LDM bằng cách sử dụng phép chuyển đổi UML-LDM. 3. Nhà mô hình dữ liệu truy cập và nhập khẩu các LDM vào RDA 4. Nhà mô hình dữ liệu chuyển đổi các LDM thành mô hình dữ liệu vật lý (PDM) và tiếp tục tạo lược đồ của cơ sở dữ liệu bằng cách sử dụng RDA. Sơ đồ dưới đây minh họa sự tương tác giữa các nhà mô hình ứng dụng và nhà mô hình dữ liệu trong kịch bản từ trên xuống dưới:
10. Hình 3. Kịch bản tích hợp từ trên xuông dưới: Từ mô hình hóa ứng dụng sang mô hình hóa dữ liệu. Chúng tôi khuyến các tổ chức xem xét việc sử dụng kịch bản từ trên xuống dưới khi tổ hợp các điều kiện sau được thỏa mãn: • Mô hình hóa ứng dụng là chủ đạo của sáng kiến dự án. • Ứng dụng xuyên suốt các đơn vị nghiệp vụ hay là các silo. • Các ứng dụng xoay quanh đối tượng (object centric) và ít đòi hỏi quản lý dữ liệu, ngoài việc lưu trữ dữ liệu lâu bền. • LDM không có sẵn. • Lược đồ của cơ sở dữ liệu vật lý không tồn tại. Tuy nhiên, đôi khi mọi người áp dụng kịch bản từ trên xuống dưới vì những lý do sai lầm. Dưới đây (trích dẫn trong ngoặc kép) là một số những lý do sai lầm cho việc quyết định áp dụng kịch bản từ trên xuống dưới; tiếp sau là lập luận phản biện chống lại việc áp dụng kịch bản từ trên xuống dưới:
11. • "Chúng tôi chưa bao giờ thực hiện LDM trước đây". Luôn phải có một lần đầu tiên. Nếu tổ chức của bạn đã bỏ qua LDM trước đây, thì nỗ lực thực hiện LDM càng sớm bao nhiêu, càng tốt cho tổ chức của bạn bấy nhiêu về lâu về dài. • "Chúng tôi không có các kỹ năng LDM". Một nhà mô hình hóa dữ liệu tốt là xứng đáng để đầu tư vì vậy bạn nên thuê người nào đó hoặc đào tạo nhân lực trong nội bộ của tổ chức của bạn về các kỹ năng LDM. • "Chúng tôi chỉ cần duy trì dữ liệu để sử dụng cho ứng dụng này". Hầu hết các ứng dụng doanh nghiệp cần phải chia sẻ các dữ liệu lâu bền với các ứng dụng doanh nghiệp khác. LDM sẽ giảm được tổng chi phí sở hữu. Cuối cùng, cần phải nói đến các khuyết điểm của việc sử dụng cách tiếp cận từ trên xuống dưới: • Các mô hình dữ liệu có thể kết dính rất chặt với các ứng dụng cụ thể. • Các mô hình lớp có thể không sẵn sàng để tái sử dụng trong LDM do việc phi chuẩn hóa và mô hình hóa lấy đối tượng làm trung tâm trong mô hình hóa ứng dụng. Từ dưới lên trên: Từ mô hình hóa dữ liệu sang mô hình hóa ứng dụng Trong kịch bản từ dưới lên trên, các phần tử mô hình hóa LDM (các thực thể, các thuộc tính và các quan hệ) được chuyển thành các phần tử mô hình hóa lớp (các lớp, các thuộc tính và các liên kết) để sử dụng trong RSA. Từ phối cảnh doanh nghiệp, về lâu dài, việc sử dụng cách tiếp cận từ dưới lên trên là thích hợp hơn so với cách tiếp cận từ trên xuống dưới vì các hạn chế của phương pháp tiếp cận từ trên xuống dưới và vì LDM có nhiều lợi ích như đã đề cập tại phần trước. Ngoài ra, phương pháp tiếp cận từ dưới lên trên cho phép tách biệt các mối quan tâm –
12. nhà mô hình hóa dữ liệu tập trung vào việc phát triển bảng từ vựng cho toàn doanh nghiệp và các mô hình dữ liệu; nhà mô hình hóa ứng dụng tập trung vào việc mô hình hóa ứng dụng. Các bước trong kịch bản này như sau: 1. Nhà mô hình dữ liệu tạo mô hình dữ liệu dưới dạng LDM trong RDA. Trong các trường hợp mà ta có một lược đồ cơ sở dữ liệu hiện đang tồn tại, nhưng không có mô hình vật lý hay lôgic, nhà mô hình dữ liệu dẫn xuất ra mô hình dữ liệu vật lý (PDM) từ lược đồ hiện có, và chuyển đổi PDM này thành một LDM. 2. Nhà mô hình dữ liệu chuyển đổi một phần, hoặc toàn bộ một LDM thành một mô hình lớp bằng cách sử dụng phép chuyển đổi LDM-UML. 3. Nhà mô hình ứng dụng truy cập và nhập khẩu các mô hình lớp vào RSA,. Sơ đồ dưới đây minh họa sự tương tác giữa nhà mô hình ứng dụng và nhà mô hình dữ liệu trong một kịch bản từ dưới lên trên: Hình 4. Kịch bản tích hợp từ dưới lên trên: Từ mô hình hóa dữ liệu sang mô
13. hình hóa ứng dụng Chúng tôi khuyến cáo các tổ chức xem xét việc sử dụng kịch bản từ dưới lên trên khi tổ hợp các điều kiện sau đây được thỏa mãn: • Một LDM cho miền đó đã có sẵn. • Có một số nguồn dữ liệu hiện đang tồn tại (cơ sở dữ liệu quan hệ hoặc loại khác). • Tổ chức mong muốn tách dữ liệu khỏi các ứng dụng và quản lý dữ liệu từ cấp độ doanh nghiệp. • Tổ chức mong muốn tạo các thông tin có thể tái sử dụng trên toàn doanh nghiệp. • Dính líu đến nhiều sáng kiến dự án; ví dụ, ứng dụng doanh nghiệp được viết lại cùng với yêu cầu để liên kết tới kho dữ liệu. • Ứng dụng rất phức tạp và thường xuyên biến động.
14. • Ứng dụng lấy dữ liệu làm trung tâm. • Dự án cần phải xem xét lại, ít ra là một phần, mô hình dữ liệu hiện có. Điều này có thể xảy ra nếu bạn phải đáp ứng các ứng dụng thừa kế, ứng dụng của bên thứ ba hoặc các giao diện dựa trên tiêu chuẩn. Cuối cùng, phương pháp tiếp cận từ dưới lên trên cũng có giá phải trả của nó: • Một số ngữ nghĩa có thể bị mất trong quá trình chuyển đổi từ một LDM sang mô hình lớp vì các LDM có chứa các ngữ nghĩa dữ liệu phong phú hơn (ví dụ như, các khóa chính) so với các mô hình lớp. • Vì rằng các LDM có xu hướng được hoàn chỉnh hơn so với mô hình lớp, nếu bạn chỉ đơn giản đẩy các LDM vào các mô hình lớp mà không có trao đổi thông tin thích hợp, thì các chi tiết có thể lấn át các nhà mô hình ứng dụng. Nếu nhà mô hình hóa ứng dụng không hiểu các LDM, thì họ có thể đi đến chỗ “phát minh lại cái bánh xe”, và định nghĩa các thực thể hoặc các thuộc tính đã có sẵn trong các LDM. Như vậy, một sự đào tạo thích hợp và trao đổi thông tin giữa nhà mô hình hóa dữ liệu và nhà mô hình hóa ứng dụng là điều cốt yếu. Lý tưởng nhất là các nhà mô hình hóa ứng dụng cần được đào tạo cách hiểu và sử dụng các mô hình dữ liệu lôgic. Gặp nhau ở giữa đường (Meet-in-the-middle) Các phần trước của bài viết mô tả các kịch bản từ trên xuống dưới và từ dưới lên trên, chủ yếu tập trung vào việc phát triển mới. Tuy nhiên, thay đổi là luôn luôn xảy ra đối với công tác phát triển phần mềm. Mô hình hóa ứng dụng và mô hình hóa dữ liệu hiếm khi làm một lần là được ngay. Để không bị lạc hậu, thì việc mô hình hóa ứng dụng và mô hình hóa dữ liệu cần phải được làm đi làm lại và đem lại giá trị kinh doanh một cách nhanh chóng. Vì vậy, các công cụ của các phương pháp mô hình hóa ứng dụng và mô hình hóa dữ liệu nên hỗ trợ khả năng cập nhật
15. các mô hình. Ví dụ, các thay đổi trong mô hình lớp có thể được cập nhật và được phản ánh vào LDM hoặc theo phương thức tự động (đối với các thay đổi đơn giản) hoặc thông qua phương thức thủ công (ở đây đòi hỏi các heuristics phức tạp – N.D: “heuristic” là phương pháp giải quyết vấn đề bằng cách sử dụng các đánh giá qua kinh nghiệm và tìm giải pháp qua thử nghiệm và rút tỉa khuyết điểm) cho sự hội tụ của mô hình và ngược lại từ LDM sang mô hình lớp. Trong thực tế, không dễ gì để quản lý tính đồng bộ hóa và quản lý thay đổi của các mô hình lớp và các mô hình dữ liệu lôgic, vì chúng nằm trong các công cụ khác nhau và thường được thực hiện bởi hai vai trò khác biệt - nhà phân tích nghiệp vụ và nhà mô hình hóa dữ liệu. Tuy nhiên, nếu ta lập kế hoạch kỹ lưỡng, có sự trao đổi thông tin xuất sắc và có cách quản lý các thay đổi có phương pháp thì ta có thể sử dụng được các đặc tính của công cụ và đạt được khả năng điều quản dữ liệu thông suốt từ đầu đến cuối (end-to-end). Có hai trường hợp sử dụng trong kịch bản gặp nhau ở giữa đường, tùy thuộc vào bạn muốn cập nhật các mô hình lớp hay các LDM của mình: 1. Một khi các mô hình lớp được chuyển đổi thành các LDM và được sử dụng trong RDA, các nhà tạo mô hình ứng dụng thực hiện một số thay đổi trong các mô hình lớp, chẳng hạn như thêm các thuộc tính mới. Chúng ta muốn cập nhật các LDM trong RDA để phản ánh các mô hình lớp đã cập nhật. Ca sử dụng này là phần mở rộng của kịch bản từ trên xuống dưới, được bổ sung thêm sự phức tạp của việc đồng bộ hóa các LDM hiện có trong RDA với các thông tin mới hoặc được sửa đổi. Các bước trong ca sử dụng thứ nhất là: 1. Nhà mô hình dữ liệu sử dụng LDM phiên bản 1 tại RDA, phiên bản này trước đó đã được chuyển đổi từ mô hình lớp phiên bản 1 trong RSA.
16. 2. Nhà mô hình ứng dụng biến đổi mô hình lớp phiên bản 1 trong RSA, sau đó chuyển đổi mô hình lớp được cập nhật (phiên bản 2) thành LDM phiên bản 1+. 3. Nhà mô hình dữ liệu truy cập và nhập khẩu LDM phiên bản 1+ vào RDA. 4. Nhà mô hình dữ liệu so sánh và hòa trộn LDM phiên bản 1+ và phiên bản 1 thành LDM phiên bản 2 trong RDA. Sơ đồ dưới đây minh họa sự tương tác giữa Nhà mô hình ứng dụng và Nhà mô hình dữ liệu trong ca sử dụng thứ nhất: Hình 5. Kịch bản gặp nhau ở giữa đường – Từ mô hình hóa ứng dụng sang mô hình hóa dữ liệu 1. Một khi các LDM được chuyển thành các mô hình lớp và được sử dụng trong RSA, thì các nhà mô hình dữ liệu tạo ra một số sửa đổi cho các LDM, chẳng hạn như thêm cột mới. Bạn nên cập nhật các mô hình lớp trong RSA để phản ánh các LDM được cập nhật. Ca sử dụng này là rất tương tự như kịch bản từ dưới lên, được bổ sung thêm sự phức tạp của việc đồng bộ hóa
17. các mô hình lớp hiện có trong RSA với những thông tin mới hoặc được sửa đổi. Các bước trong ca sử dụng thứ hai là: 1. Nhà mô hình ứng dụng sử dụng mô hình lớp phiên bản 1 trong RSA, mà trước đó đã được chuyển đổi từ LDM phiên bản 1 tại RDA. 2. Nhà mô hình dữ liệu biến đổi LDM phiên bản 1 trong RDA, sau đó chuyển đổi các LDM cập nhật (phiên bản 2) thành phiên bản mô hình lớp 1+. 3. Nhà mô hình ứng dụng truy cập và nhập khẩu mô hình lớp phiên bản 1+ vào RSA. 4. Nhà mô hình ứng dụng so sánh và hòa trộn mô hình lớp phiên bản 1+ và phiên bản 1 thành mô hình lớp phiên bản 2 trong RSA. Sơ đồ dưới đây cho thấy sự tương tác giữa nhà mô hình ứng dụng và nhà mô hình dữ liệu trong ca sử dụng thứ hai: Hình 6. Kịch bản gặp nhau ở giữa đường - Từ mô hình hóa dữ liệu sang mô
18. hình hóa ứng dụng Về đầu trang Các phép chuyển đổi mô hình Các phép chuyển đổi mô hình là cốt lõi của việc tích hợp mô hình hóa ứng dụng với mô hình hóa dữ liệu. Trong kịch bản từ trên xuống dưới được thảo luận ở phần trên, các mô hình lớp được chuyển thành các mô hình dữ liệu lôgic bằng cách sử dụng phép chuyển đổi UML-LDM; ở kịch bản từ dưới lên, các mô hình dữ liệu lôgic được chuyển thành các mô hình lớp bằng cách sử dụng phép chuyển đổi LDM-UML. Mô hình lớp UML Mô hình lớp định nghĩa: • Mô hình và các gói: Chúng được dùng làm các thành phần cấu trúc và không gian tên cho các phần tử mô hình khác. Một gói có thể chứa các gói,
19. các sơ đồ, các lớp, các quan hệ kết hợp, các lớp của quan hệ kết hợp và các kiểu dữ liệu. • Các lớp: Chúng biểu diễn các khái niệm trong hệ thống đang được mô hình hóa. Các cá thể của cùng một lớp chia sẻ các đặc điểm chung. Một lớp có: o Các thuộc tính: Là mô tả của các đặc trưng của một lớp. Một thuộc tính, ngoài những thứ khác, có một kiểu là kiểu giá trị mà nó có thể nhận. o Tổng quát hóa: Một lớp có thể có sự tổng quát hóa giữa nó và các lớp khái quát hơn, giống như trong các quan hệ phân loại, Lớp hoàn toàn nhất quán với lớp khái quát hơn và có chứa các thuộc tính bổ sung. • Các quan hệ kết hợp: Chúng biểu diễn các mối quan hệ ngữ nghĩa giữa hai lớp mà có dính líu đến các kết nối giữa các cá thể của chúng. Ngoài dạng quan hệ kết hợp đơn giản, ta có hai dạng quan hệ bổ sung: o Kết tập: Là dạng quan hệ kết hợp xác định mối quan hệ tổng thể - bộ phận trong một kết tập (tổng thể) với bộ phận cấu thành. o Cấu thành: Là một dạng kết tập nhưng hỗn hợp (tổng thể) có quyền sở hữu các bộ phận mạnh hơn và các bộ phận và hỗn hợp có cùng thời gian sống. Một bộ phận chỉ có thể thuộc về một hỗn hợp tại một thời điểm. • Các lớp của quan hệ kết hợp: Một lớp quan hệ kết hợp là một quan hệ kết hợp, và quan hệ kết hợp này cũng là một lớp. Một lớp quan hệ kết hợp nối hai lớp lại với nhau và có các thuộc tính.
20. • Các kiểu dữ liệu: Một kiểu dữ liệu là một cái mô tả của một tập hợp các giá trị. Kiểu dữ liệu bao gồm: o Kiểu dữ liệu nguyên thủy đã định nghĩa trước: Boolean, Number, String, UnlimitedNatural o Kiểu dữ liệu do người dùng định nghĩa: Kiểu dữ liệu nguyên thủy hoặc kiểu bảng kê Xin vui lòng xem lại Hình 1 về mô hình lớp mẫu. Mô hình dữ liệu lôgic của RDA Mô hình lôgic dữ liệu xác định: • Các gói: Chúng dùng làm các thành phần cấu trúc cho các phần tử mô hình khác. Một gói có thể chứa các gói, các sơ đồ, các thực thể và các miền. • Các thực thể: Chúng biểu diễn các khái niệm, sự kiện, con người, địa điểm hoặc sự vật mà các thông tin được lưu giữ. Các cá thể của cùng một thực thể chia sẻ các đặc điểm chung. Các thực thể có thể độc lập hoặc phụ thuộc. Một thực thể có các cá thể không thể được xác định đơn nhất nếu không xác định mối quan hệ của nó đến một hoặc nhiều thực thể khác là một thực thể phụ thuộc; trái lại, nó là một thực thể độc lập. Một thực thể có: o Các thuộc tính: mô tả các đặc điểm của một thực thể. Một thuộc tính, ngoài những thứ khác, có một kiểu là kiểu giá trị mà nó có thể nhận o Khóa chính: Là một thuộc tính hoặc các thuộc tính nhận diện duy nhất một cá thể của thực thể
21. o Tổng quát hóa: một thực thể có thể có sự tổng quát hóa giữa nó và các thực thể khái quát hơn, tức là các quan hệ phân loại. Thực thể hoàn toàn nhất quán với lớp khái quát hơn và có chứa các thuộc tính bổ sung. • Các quan hệ: Chúng biểu diễn các kết nối, liên kết, hay là quan hệ kết hợp giữa hai thực thể. Có ba loại quan hệ: o Quan hệ nhận diện: Là mối quan hệ theo đó một cá thể của thực thể con được xác định thông qua quan hệ kết hợp của nó với một thực thể cha. Các thuộc tính khóa chính của thực thể cha trở thành các thuộc tính khóa chính của thực thể con. o Quan hệ không nhận diện: Là mối quan hệ theo đó một cá thể của thực thể con không được xác định thông qua các liên kết của nó với một thực thể cha. Các thuộc tính khóa chính của thực thể cha trở thành các thuộc tính không là khóa của thực thể con. o Quan hệ nhiều - nhiều: Là một quan hệ kết hợp giữa hai thực thể, trong đó mỗi cá thể của thực thể đầu tiên được kết hợp với không, một, hay nhiều cá thể của thực thể thứ hai và mỗi cá thể của thực thể thứ hai được kết hợp với không, một, hay nhiều cá thể của thực thể đầu tiên. • Các kiểu dữ liệu: Kiểu dữ liệu là cái mô tả của một tập hợp các giá trị. Kiểu dữ liệu bao gồm: o Kiểu dữ liệu đã định nghĩa trước: BINARY, BLOB, BOOLEAN, CHAR, CLOB, DATALINK, DATE, DECIMAL, DOUBLE, FLOAT, INTEGER, INTERVAL, LONG, ROWID, SHORT, TIME, TIMESTAMP, VARBINARY, VARCHAR, XML
22. o Kiểu dữ liệu do người dùng định nghĩa: các miền nguyên tử (atomic domains) Xin vui lòng xem lại Hình 2 về mô hình dữ liệu lôgic mẫu. Từ trên xuống dưới: Từ mô hình lớp sang mô hình dữ liệu lôgic Từ các thảo luận ở trên có thể thấy rằng mô hình lớp UML và mô hình dữ liệu lôgic của RDA rất khớp với nhau về mặt cấu trúc và ngữ nghĩa mô hình hóa. Kết quả là, việc chuyển đổi mô hình lớp thành một mô hình dữ liệu lôgic nói chung là đơn giản và không bị mất mát thông tin. Bảng 1 minh họa ánh xạ từ một mô hình lớp (nguồn) sang một mô hình dữ liệu lôgic (đích). Trong bảng này ta cần chú ý: • Một lớp không có khóa chính, nó có một mã nhận diện đối tượng (OID) ẩn. OID này được chuyển đổi thành khóa đại diện. • Một quan hệ kết hợp đơn giản được chuyển thành quan hệ không nhận diện nếu một trong hai đầu của quan hệ kết hợp có số bội là 0,1 hoặc 1; trái lại nó được chuyển thành quan hệ nhiều-nhiều. • Một thuộc tính có thể có tham chiếu lớp làm kiểu của thuộc tính đó, nó có ngữ nghĩa giống hệt với một kết tập. Do đó, tham chiếu lớp được chuyển đổi thành quan hệ không nhận diện. • Một lớp của quan hệ kết hợp là một khái niệm không tồn tại trong mô hình dữ liệu lôgic. Nó được chuyển thành một thực thể và thành hai mối quan hệ để bảo tồn ngữ nghĩa của lớp của quan hệ kết hợp.
23. Bảng 1. Ánh xạ UML-LDM Hình 7 cho thấy mô hình dữ liệu lôgic đích được tạo ra bởi phép chuyển đổi UML- LDM bằng cách sử dụng mô hình lớp ví dụ mẫu trong Hình 1. Khi so sánh các mô hình nguồn và đích, xin hãy lưu ý các chuyển đổi sau: • Khóa đại diện (ví dụ như, Invoice ID của Invoice) đã được tạo ra cho mỗi thực thể. • Thừa kế khóa (ví dụ như, Invoice ID được chuyển từ Invoice sang cho ProductInvoice) xảy ra cho sự tổng quát hóa. • Di trú khóa (ví dụ như, Invoice Id được chuyển thành invoiceInvoice Id từ Invoice sang cho InvoiceItem) xảy ra cho quan hệ cấu thành.
24. • Di trú khóa (ví dụ như, Invoice Id được chuyển thành mainInvoiceID từ Invoice sang cho Invoice ) xảy ra cho quan hệ kết tập. • Theo mặc định, đối với việc di trú khóa, thì tên của thuộc tính khóa ngoài của con được tạo ra bằng cách ghép tên vai trò của cha vào trước tên của thuộc tính khóa chính của cha. Hình 7. Mô hình dữ liệu loogic được tạo ra bởi phép chuyển đổi UML-LDM Lược khai của mô hình dữ liệu lôgic của UML Không phải tất cả các lớp được định nghĩa trong quá trình mô hình hóa ứng dụng nhất thiết phải liên quan đến quá trình mô hình hóa dữ liệu hoặc có dữ liệu tồn tại lâu bền; tương tự như vậy, không phải tất cả các kiểu nguyên thủy hoặc các bảng kê nhất thiết phải tương ứng với các kiểu dữ liệu cần thiết để mô hình hóa dữ liệu hoặc cho dữ liệu tồn tại lâu bền. Lược khai của mô hình dữ liệu lôgic của UML có thể được sử dụng để: • Cho phép người sử dụng kiểm soát những lớp nào, các kiểu nguyên thủy nào, hoặc các bảng kê nào chuyển đổi sang mô hình dữ liệu lôgic.
25. • Chỉ rõ các khái niệm quan trọng cho mô hình hóa dữ liệu lôgic nhưng lại thiếu sót trong UML, bao gồm: • o Một (hoặc nhiều) thuộc tính khóa chính o Kiểu dữ liệu do người dùng định nghĩa: cung cấp nhiều thông tin hơn những gì có thể được xác định bằng các kiểu dữ liệu nguyên thủy hoặc các bảng kê o Tính toàn vẹn tham chiếu: ví dụ như, quy tắc xóa thực thể cha Về bản chất thì lược khai của mô hình dữ liệu lôgic của UML cho phép người sử dụng thực hiện mô hình hóa dữ liệu lôgic bằng cách sử dụng UML trong RSA. Bảng 2 minh họa các bản mẫu (stereotypes) và các thuộc tính được lược khai của mô hình dữ liệu lôgic của UML cung cấp. Xin lưu ý: • Bảng kê hoặc các kiểu nguyên thủy có thể được rập bản mẫu làm miền (Domain). Nếu vậy, các thông tin bổ sung (ví dụ như, kiểu cơ sở) có thể được chỉ rõ. • Lớp có thể được rập bản mẫu làm thực thể. Theo mặc định, chúng tồn tại lâu bền và không sử dụng khóa đại diện. • Các thuộc tính sẽ luôn luôn được rập bản mẫu làm thuộc tính. Các thuộc tính này là không bắt buộc theo mặc định. • Các thuộc tính có thể được rập bản mẫu làm khóa chính (PrimaryKey). • Các quan hệ kết hợp và các lớp của quan hệ kết hợp luôn luôn được rập bản mẫu làm các quan hệ. Nếu vậy, có thể chỉ rõ các tên của thuộc tính khóa
26. ngoài (dưới dạng một cặp tên thuộc tính khóa chính, tên thuộc tính khóa ngoài) và quy tắc xóa thực thể cha (NONE / RESTRICT / CASCADE / SET NULL / SET DEFAUL). Trong tương lai, quy tắc xóa thực thể con cũng được chỉ rõ. Bảng 2. Lược khai của mô hình dữ liệu lôgic của UML Bảng 3 cho thấy ánh xạ từ một mô hình lớp (nguồn) sang mô hình dữ liệu lôgic (đích) khi lược khai của mô hình dữ liệu lôgic được áp dụng cho mô hình lớp. Nên lưu ý các điểm sau: • Chỉ có các lớp được rập bản mẫu làm thực thể (Entity) được chuyển đổi thành thực thể. Theo mặc định, chúng tồn tại lâu bền và không sử dụng khóa đại diện.
27. • Các thuộc tính được rập bản mẫu làm khóa chính (PrimaryKey) được chuyển đổi thành các thuộc tính khóa chính, trong trường hợp này các thuộc tính được tạo ra là bắt buộc. • Đối với các quan hệ kết hợp, lớp của quan hệ kết hợp, nếu các tên thuộc tính khóa ngoài và quy tắc xóa thực thể cha được chỉ rõ, thì chúng được sử dụng cho các mối quan hệ được tạo ra. Trong tương lai quy tắc xóa thực thể con, nếu được chỉ rõ, cũng sẽ được sử dụng. • Chỉ có các kiểu nguyên thủy /các bảng kê được rập bản mẫu làm miền (Domain) là được chuyển thành miền nguyên tử. Bảng 3. Ánh xạ UML-LDM với Lược khai của mô hình dữ liệu lôgic Hình 8 hiển thị mô hình lớp mẫu với lược khai của mô hình dữ liệu lôgic được áp dụng. Xin lưu ý:
28. • Tất cả các kiểu nguyên thủy được rập bản mẫu làm miền. • Tất cả các lớp được rập bản mẫu làm thực thể. • Các thuộc tính ID của Invoice và InvoiceItem đã được rập bản mẫu làm khóa chính (PrimaryKey). Hình 8. Mô hình lớp mẫu với Lược khai của mô hình dữ liệu lôgic Hình 9 hiển thị mô hình lôgic dữ liệu đích được tạo ra bởi phép chuyển đổi UML- LDM. Nguồn của các mô hình lớp mẫu được sử dụng trong phép chuyển đổi này là từ hình 8. Khi so sánh các mô hình nguồn và đích, xin lưu ý: • Không có khóa đại diện nào được tạo ra. Thay vào đó, các thuộc tính khoá chính (ID của Invoice và ID của InvoiceItem) được tạo ra. • Sự thừa kế khóa (khóa ID từ Invoice sang cho ProductInvoice) xảy ra cho quan hệ tổng quát hóa. • Sự di trú khóa (Từ Invoice Id thành invoiceID khi chuyển từ Invoice sang cho InvoiceItem) xảy ra cho quan hệ cấu thành.
29. • Sự di trú khóa (Từ ID thành mainID khi chuyển từ Invoice sang cho Invoice) xảy ra cho quan hệ kết tập. • Theo mặc định, đối với việc di trú khóa thì tên của thuộc tính khóa ngoài của con được tạo ra bằng cách gắn thêm tên vai trò của cha vào trước tên của thuộc tính khóa chính của cha. Hình 9. Mô hình dữ liệu lôgic sinh ra bởi phép chuyển đổi UML-LDM với lược khai của mô hình dữ liệu lôgic Từ dưới lên trên: Từ mô hình dữ liệu lôgic thành mô hình lớp Tương tự như chuyển đổi từ trên xuống dưới, việc chuyển đổi mô hình dữ liệu lôgic thành mô hình lớp nói chung là đơn giản và không bị suy hao thông tin. Bảng 4 cho thấy ánh xạ từ một mô hình dữ liệu lôgic (nguồn) đến một mô hình lớp (đích).
30. Bảng 4. Ánh xạ LDM UML Hình 10 hiển thị mô hình lớp đích được tạo ra bởi phép chuyển đổi LDM-UML. Nguồn của mô hình dữ liệu lôgic mẫu được sử dụng trong phép chuyển đổi này là từ Hình 2. Khi so sánh các mô hình nguồn và đích, xin lưu ý: • Thông tin về khóa chính (ID của Invoice) bị mất trong mô hình lớp vì mô hình lớp UML không hỗ trợ khái niệm khóa chính. • Các thuộc tính khóa ngoài (invoiceID của InvoiceItem) không được chuyển đổi sang mô hình lớp vì chúng được tạo ra bởi việc di trú khóa trong mô hình dữ liệu lôgic và không là vốn dĩ phải có cho mô hình này.
31. Hình 10. Mô hình lớp được sinh ra bởi phép chuyển đổi LDM-UML Lược khai có thể được áp dụng cho mô hình lớp đích khi chuyển đổi LDM-UML. Bảng 5 cho thấy ánh xạ từ một mô hình dữ liệu lôgic (nguồn) đến một mô hình lớp (đích) với lược khai của mô hình dữ liệu lôgic được áp dụng. Xin lưu ý: • Các thực thể được chuyển đổi thành lớp bản mẫu Entity. • Các thuộc tính khóa chính được chuyển đổi thành các thuộc tính bản mẫu PrimaryKey. • Các miền nguyên tử được chuyển đổi thành các kiểu nguyên thủy và các bảng kê được rập bản mẫu làm Domain.
32. Bảng 5. Ánh xạ LDM-UML với lược khai của mô hình dữ liệu lôgic Hình 11 cho thấy các mô hình lớp đích được tạo ra bởi phép chuyển đổi LDM- UML, với lược khai của mô hình dữ liệu lôgic được áp dụng cho mô hình lớp đích. Nguồn của mô hình lôgic dữ liệu mẫu được sử dụng trong chuyển đổi này là từ Hình 2. Khi so sánh các mô hình nguồn và đích, xin lưu ý: • Thông tin về khóa chính (ID của Invoice) được bảo toàn trong mô hình lớp. • Các thuộc tính khóa ngoài (invoiceID của InvoiceItem) không được chuyển đổi sang mô hình lớp vì chúng được tạo ra bởi việc di trú khóa trong mô hình dữ liệu lôgic và không là vốn dĩ phải có cho mô hình này. Hình 11. Mô hình UML được sinh ra bởi phép chuyển đổi LDM-UML với
33. lược khai của mô hình dữ liệu lôgic Về đầu trang Kết luận Bài viết này cung cấp một tổng quan ở mức cao về RSA và RDA và việc tích hợp chúng. Bạn đã xem ba kịch bản tích hợp và tìm hiểu các tiêu chuẩn cho việc chấp nhận một cách tương ứng kịch bản từ trên xuống dưới và kịch bản từ dưới lên trên. Để tạo được các mô hình ứng dụng và các mô hình dữ liệu tốt, thì chỉ hiểu biết cách sử dụng các công cụ là chưa đủ. Cũng không kém phần quan trọng là ta phải biết lý do để áp dụng một kịch bản nhất định, để xác định một quy trình quản lý các thay đổi vững mạnh và lặp lại được, và để tạo ra một chiến lược thúc đẩy sự hiệp lực giữa mô hình hóa ứng dụng và mô hình hóa dữ liệu. Việc tích hợp thành công mô hình hóa ứng dụng và mô hình hóa dữ liệu có thể cũng cần phải có các thay đổi về mặt tổ chức và văn hóa. Chúng tôi hy vọng rằng bài viết này sẽ giúp
34. bạn khởi động các nỗ lực mô hình hóa ứng dụng và mô hình hóa dữ liệu được tích hợp của mình. Bài viết này cũng cung cấp các thảo luận chi tiết về các phép chuyển đổi UML- LDM và LDM-UML cũng như lược khai của mô hình dữ liệu lôgic của UML. Nói chung là có lợi khi ta áp dụng lược khai mô hình dữ liệu lôgic vào mô hình lớp cho dù mô hình lớp là nguồn hay là được tạo ra như là đích. Về chính thức, nó cho phép người sử dụng kiểm soát những lớp nào, các kiểu dữ liệu nguyên thủy nào, các bảng kê nào sẽ chuyển đổi sang mô hình dữ liệu logic và chỉ rõ các khái niệm và thông tin quan trọng cho việc mô hình hóa dữ liệu lôgic nhưng thiếu vắng trong UML. Cuối cùng, nó làm cho phép chuyển đổi có thể đảo ngược được vì các khái niệm và thông tin chủ yếu cho việc mô hình hóa lôgic dữ liệu được bảo toàn trong mô hình lớp đã sinh ra. Như hình 12 đã minh họa, việc mô hình hóa dữ liệu lôgic là thanh chốt khi tích hợp mô hình hóa dữ liệu. Trong bài viết này bạn đã xem cách mô hình hóa ứng dụng trong RSA có thể được tích hợp với mô hình hóa dữ liệu lôgic trong RDA như thế nào. Việc tích hợp giữa mô hình hóa dữ liệu logic và mô hình hóa dữ liệu quan hệ là một đặc tính tiêu chuẩn của RDA. Việc tích hợp giữa mô hình hóa nghiệp vụ trong WBM và mô hình hóa dữ liệu lôgic trong RDA, cũng như việc tích hợp giữa mô hình hóa dữ liệu logic và mô hình hóa dữ liệu XML trong RDA, đã làm việc bình thường và sẽ được thảo luận trong một bài viết sắp tới tại trang developerWorks. Hình 12. Mô hình hoá dữ liệu loogic giống như một chốt an toàn (Lynch Pin)
35. cho việc tích hợp mô hình hoá dữ liệu Mục lục • Các kịch bản tích hợp • Các phép chuyển đổi mô hình • Kết luận