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

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ừ n

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ô

• Ứ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ô