Tích hợp Rational Software Architect với Rational Data Architect

Chia sẻ: Nguyen Nhi | Ngày: | Loại File: PDF | Số trang:34

Thêm vào BST

Báo xấu

92
lượt xem 16
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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...

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Tích hợp Rational Software Architect với Rational Data Architect

Tài liệu Đề tài: Tích hợp Rational Software Architect với Rational Data Architect
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
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.
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 •
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+ +.
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ư
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.
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.
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:
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:
"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 –
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ô
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. •
Ứ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
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.
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
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ô
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,
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ó: 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 o 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. 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 o 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: Kết tập: Là dạng quan hệ kết hợp xác định mối quan hệ tổng thể - bộ o phận trong một kết tập (tổng thể) với bộ phận cấu thành. 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 o 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.
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: Kiểu dữ liệu nguyên thủy đã định nghĩa trước: Boolean, Number, o String, UnlimitedNatural Kiểu dữ liệu do người dùng định nghĩa: Kiểu dữ liệu nguyên thủy o 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ó: 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, o ngoài những thứ khác, có một kiểu là kiểu giá trị mà nó có thể nhận Khóa chính: Là một thuộc tính hoặc các thuộc tính nhận diện duy o nhất một cá thể của thực thể