1. Trang chủ
  2. » Giáo Dục - Đào Tạo

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

35 198 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Nội dung

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ố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... 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 • Các kiểu... 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á... 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 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... 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... không sử dụng khóa đại diện • 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 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ú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 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... 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... 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) 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 . 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. á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. 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

Ngày đăng: 08/08/2014, 14:20

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w