UML: Giao diện (Interface)
Giao diện là tập hợp những thao tác quan sát được từ bên ngoài của một lớp và/ hoặc một thành phần, không có nội dung cài đặt riêng lớp đó.
OWL: owl:Class, rdfs:subClassOf
OWL sẽ định nghĩa giao diện như một lớp (owl:Class), và định nghĩa thêm lớp thừa kế lớp đó (rdfs:subClassOf) và có các thành phần để cài đặt lớp cha. Ta xét ví dụ sau:
Hình 2.5. Ví dụ minh họa Interface.
Tổng quát hóa là đi từ các lớp dưới lên trên, sau đó hình thành lớp tổng quát (lớp trên, lớp cha), tức là cây cấu trúc từ lá đến gốc. Khi đó tổng quát hóa chính là quan hệ kế thừa giữa các lớp. Trong đó, lớp con (lớp dưới, lớp kế thừa hay lớp dẫn xuất) kế thừa trực tiếp các thuộc tính và các phương thức thuộc loại công khai (public), hay được bảo vệ (protected) của lớp cha (lớp trên hay lớp cơ sở).
Trong OWL sẽ được biểu diễn bằng owl:subClassOf. Ta có ví dụ sau:
Hình 2.6. Minh họa quan hệ thừa kế.
Lớp B thừa kế lớp A:
Ta sẽ định nghĩa lớp A, sau đó định nghĩa lớp B là lớp con của lớp A: Ví dụ trên được chuyển sang OWL Ontology:
Khi muốn khai báo hai lớp con (B và C cùng thừa kế một lớp cha A) tách rời nhau thì ta sẽ sử dụng:
owl:disjointWith
2.2.6. Liên kết (Association)
UML : Mối quan hệ liên kết OWL: owl:ObjectProperty
Một liên kết là một sự nối kết giữa các lớp, nó liên quan về ngữ nghĩa giữa các đối tượng của các lớp tham gia. Lớp và liên hệ giữa các lớp là những công cụ rất mạnh mẽ cho việc mô hình hóa các hệ thống phức tạp, ví dụ như cấu trúc sản phẩm, cấu trúc văn bản và tất cả các cấu trúc thông tin khác.
Ví dụ:
Hình 2.7. Lớp Author liên kết với lớp Computer.
Theo nguyên tắc, khi chuyển liên kết sang OWL Ontology, thì liên kết sẽ được chuyển thành một thuộc tính đối tượng (kiểu ObjectProperty). Tùy từng loại liên kết thì có quy tắc chuyển khác nhau.
2.2.6.1. Trường hợp Liên kết theo một hướng Ví dụ:
Hình 2.8. Minh họa liên kết một hướng.
Khi đó, trong OWL Ontology, tạo ra 2 lớp HTBanHang và PhieuBanHang, các thuộc tính của lớp tương ứng và thêm một thuộc tính đối tượng (ObjectProperty) là “Ghi_nhan” sẽ được tạo ra trong lớp HTBanHang để liên kết hai lớp HTBanHang và PhieuBanHang. Trong trường hợp không có tên vai trò
2.2.6.2. Liên kết theo hai hướng
Với liên kết theo hai hướng, với mỗi liên kết ta cũng chuyển đổi tương tự như đối với liên kết theo 1 hướng. Tùy vào chiều mũi tên mà ta có thuộc tính đối tượng của vai trò liên kết đó sẽ ở lớp nào, và thuộc tính đối tượng còn lại của vai trò liên kết có thể theo kiểu ngược lại (inverseOf) với thuộc tính của vai trò kia hoặc không. Ví dụ:
Hình 2.9. Minh họa mối liên kết hai chiều.
Ta sẽ xây dựng 2 lớp Customer và lớp Account, một thuộc tính đối tượng Holds thuộc lớp Customer, và thuộc tính Owned by thuộc lớp Account. Thuộc tính Owned by theo kiểu đảo ngược với thuộc tính Holds. Vì vậy, trong OWL, sơ đồ trên sẽ được chuyển sang OWL như sau:
2.2.6.3. Lớp liên kết
Ta xét ví dụ sau:
Hình 2.10. Lớp liên kết.
Khí đó, lớp Employment sẽ là lớp liên kết của Company và lớp Person. Lớp liên kết sẽ có thêm thuộc tính dữ liệu (DatatypeProperty) là “isAssociationClass”, với kiểu Boolean và giá trị cho thuộc tính này là true.
Ngoài ra, lớp liên kết còn có thêm hai thuộc tính đối tượng nữa là “firstOf_{association_class_name }”, và “secondOf_{association_class_name}”.
Vì vậy, theo như ví dụ trên, lớp liên kết sẽ được biểu diễn như sau:
Để đặt giá trị cho isAssociationClass:
2.2.7. Các vai trò (Roles)
Các vai trò trong liên kết được chuyển sang là thuộc tính đối tượng (ObjectProperty). Đồng thời nó được khai báo là thuộc tính con (subObjectPropertyOf) của thuộc tính mô tả liên kết mà nó tham gia.
Ví dụ như sau:
Hình 2.11. Ví dụ minh họa các vai trò.
Vai trò “instructor” được chuyển sang thành thuộc tính ObjectProperty trong lớp StaffMember, thuộc tính này được khai báo là thuộc tính con (subObjectPropertyOf) của thuộc tính đối tượng “instructs”.
2.2.8. Các thuộc tính (Attributes)
Hình 2.12. Minh họa thuộc tính lớp.
Thuộc tính có giá trị là kiểu dữ liệu (DatatypeProperty) và thuộc tính có giá trị là kiểu đối tượng ( tức là các lớp). Khai báo thuộc tính dữ liệu:
Hình 2.13. Minh họa ObjectPropeprty.
Ví dụ trên được chuyển sang OWL:
2.2.9. Ràng buộc số lượng
UML : Số lượng trong liên hệ
Số lượng được ghi ở phía đầu đường thẳng thể hiện liên hệ, sát vào lớp là miền áp dụng của nó. Phạm vi của số lượng phần tử trong liên hệ có thể từ 0-tới-1 (0..1), 0-tới-nhiều (0..*), hay một-tới-nhiều (1..*), hai (2), năm-tới-mười một (5..11). Cũng có thể miêu tả một dãy số ví dụ (1,4,6, 8..12). Giá trị mặc định là 1.
Khi đó, dịch vụ tài khoản tiết kiệm (Savings Account Service) sẽ có một tới nhiều tài khoản tiết kiệm (Saving Account). Khách hàng có thể có một hoặc nhiều tài khoản, còn tài khoản thì được sở hữu bởi từ 1 đến 3 khách hàng. v.v.
Ta có các giàng buộc về số lượng sẽ được biểu diễn trong OWL như sau:
2.2.9.1. owl:cardinality
Ràng buộc với số lượng phần tử chính xác với số lượng cụ thể.
Ví dụ: Với lớp sinh vật, số lượng giới tính (với thuộc tính là “gioi_tinh”) chỉ là [3] chẳng hạn. Khi đó ta sẽ có giàng buộc như sau:
2.2.9.2. owl:minCardinality
Ràng buộc với số lượng phần tử nhỏ nhất như [1..*]
Ví dụ như với sơ đồ quản lý tài khoản tiết kiệm, Dịch vụ quản lý tài khoản tiết kiệm quản lý ít nhất một tài khoản tiết kiệm. Khi đó ta sẽ có:
2.2.9.3. owl:maxCardinality
Khoảng giá trị:
Nếu số lượng phần tử giới hạn trong một khoảng ví dụ [1..3] thì ta sẽ khai báo ràng buộc với owl:minCardinality với giá trị là 1, và owl:maxCardinality với giá trị là 3, tương tự cách khai báo như trên.
Nếu số lượng phần tử cụ thể là các số (có nhiều giá trị của số lượng phần tử) ta có thể thêm vào với owl:cadinality, tương tự như các ví dụ trên.
2.2.10. Mối quan hệ phụ thuộc
UML: Mối quan hệ phụ thuộc (Dependencies)
Hình 2.15. Minh họa mối sự phụ thuộc.
Do Lớp Sale có tham số của phương thức là kiểu lớp ProductDescription nên đó là một kiểu phụ thuộc. Đối với quan hệ phụ thuộc thì trong OWL sẽ được biểu diễn như sau:
Ta sẽ tạo ra một thuộc tính là “Dependency” kiểu ObjectProperty. Các owl:domain và owl:range sẽ là các lớp tham gia vào mối quan hệ phụ thuộc này. Như trong ví dụ, trong lớp Sale sẽ có thêm một thuộc tính là “Dependency” có kiểu ObjectProperty.
2.2.10.1. Phụ thuộc vào một lớp
Hình 2.16. Quan hệ phụ thuộc.
Khi đó, ta sẽ chuyển đổi sang OWL như sau:
2.2.10.2. Phụ thuộc vào nhiều lớp
Ví dụ như lớp A phụ thuộc lớp B và lớp C thì ta sử dụng owl:unionOf.
Đối với những liên kết hoặc thuộc tính có tên tương đương nhau, thì khi đó ta sẽ chuyển liên kết hay thuộc tính tương đương về một thuộc tính kiểu đối tượng (kiểu ObjectProperty). Với liên kết có tên tương đương nhau thì miền và phạm vi sẽ được xác định thông qua các lớp mà liên kết chỉ đến. Các lóp đó sẽ được kết hợp bằng “owl:unionOf” tương tự như trên và phần liên kết đã giải thích cách chuyển đổi liên kết sang OWL. Với các thuộc tính tương đương nhau, tương đương về tên lẫn giá trị thì chúng cũng được chuyển giống như với liên kết.
2.2.11. Liệt kê
Trong lớp bao gồm các thể hiện của lớp, với lớp kiểu liệt kê này, trong OWL Ontology ta sẽ sử dụng owl:oneOf. Ta xét ví dụ sau:
Hình 2.17. Minh họa kiểu liệt kê.
Ta có:
2.2.12. Kết tập
UML: Kết tập
Kết tập là một trường hợp đặc biệt của liên hệ. Kết tập biểu thị rằng quan hệ giữa các lớp dựa trên nền tảng của nguyên tắc "một tổng thể được tạo thành bởi các bộ phận". Nó được sử dụng khi chúng ta muốn tạo nên một thực thể mới bằng cách tập hợp các thực thể tồn tại với nhau. Một ví dụ tiêu biểu của kết tập là chiếc xe ô tô gồm có bốn bánh xe, một động cơ, một khung gầm, một hộp số, v.v....
Xét ví dụ sau: Một lớp tài khoản được tạo bởi các lớp chi tiết về khách hàng, các lệnh giao dịch đối với tài khoản cũng như các quy định của nhà băng.
Hình 2.18. Minh họa mối quan hệ kết tập.
Trong OWL không có một cấu trúc xác định nào cho mối quan hệ Bộ phận- Toàn bộ. Kết tập được xem như một loại liên kết. Ví vậy, với mối quan hệ này thì lớp tổng thể cần phải có thêm thuộc tính “has_{tên lớp bộ phận}” kiểu ObjectProperty. Và ở mỗi lớp bộ phận, nên có thêm thuộc tính là “{lớp bộ phận}_partOf_{tên lớp tổng thể}”.
Với ví dụ như trên, ta sẽ có:
2.2.13. Phương thức
Đối với phương thức, OWL không có cấu trúc để hỗ trợ. Điều này đòi hỏi, cần phải có luật chuyển đổi riêng. Khi đó, ta sẽ khai báo Phương thức như một lớp riêng và có quan hệ kết tập với lớp, có nghĩa là Lớp chứa các phương thức. Các thuộc tính Operator và các liên kết được thể như hình dưới.
Class +name: String +isAbstract: Boolean Operation +name: String +isAbstract: Boolean +visibility: VisibilityKind +Commonality: Boolean Parameter +name: String +direction: ParameterDirectionKind +class +ownedOperation 0..1 * +operation +ownedParameter 0..1 * +superClass +subClass * *
Hình 2.19. Siêu mô hình của biểu đồ lớp UML.
Khi đó, ta sẽ tạo thêm 2 lớp là lớp Parameter (tham số) và lớp Type với hai lớp con kế thừa nó là VisibilityKind và lớp ParameterDirectionKind.
Khi đó ta sẽ có quy tắc chuyển đổi đối với phương thức trong UML như sau:
o Lớp Class sẽ có thêm một thuộc tính kiểu đối tượng là “ownedOperation” với owl:domain là Class, và owl:range là Operation.
Xây dựng lớp Operation với các thuộc tính:
o op_name: DatatypeProperty: String. Tên phương thức
o isAbstract: DatatypeProperty: Boolean
Kiểm tra xem phương thức có là phương thức ảo không? Nếu là phương thức ảo, thuộc tính này nhận giá trị true, nếu không là false.
o visibility: ObjectProperty:VisibilityKind
Thuộc tính này kiểu Phương thức thuộc loại nào? public, protected hay private, có liên kết với lớp VisibilityKind.
o commonality: DatatypeProperty:Boolean.
Tiếp đó ta sẽ xây dựng lớp Parameter (Tham số):
o para_name: DatatypeProperty: String. Tên tham số
o direction: ObjectProperty: ParameterDirectionKind
Dạng trả về của tham số là in, out, inout, return. Nó rdf: range là lớp ParameterDirectionKind.
Tiếp theo là xây dựng hai lớp VisibilityKind và ParmeterDirectionKind. Lớp VisibilityKind có thuộc tính:
o visibilityKind: DatatypeProperty: String.
Có 4 lựa chọn cho phạm vi thuộc tính là :
o Public: Mọi lớp đều nhìn thấy thuộc tính, phương thức.
o Private: Lớp khác không nhìn thấy thuộc tính, phương thức.
o Protected: Các lớp thừa kế có thể nhìn thấy.
o Package và Implementation: thuộc tính, phương thức là public đối với với các lớp trong gói.
Lớp ParameterDirectionKind có thuộc tính:
paraDirectionKind: DatatypeProperty:String.
Các kiểu parameterDirectionKind (các kiểu tham số) gồm có: in, out, inout
và return.
Còn để ví dụ mình họa cho cách chuyển đổi từ phương thức này, chúng tôi sẽ nói rõ hơn trong phần triển khai ứng dụng ở chương 3.
Vậy là ta đã vừa xây dựng được những quy tắc chuyển đổi từ các yếu tố trong UML sang OWL. Trên đây là một số các luật cơ bản để có thể chuyển đổi từ mô hình UML sang OWL. Do đó, việc chuyển đổi này hoàn toàn có thể thực hiện được bằng công cụ Protégé. Và sau đây, chương 3 sẽ giới thiệu về các quy trình để thực hiện việc kiểm tra xem kết quả áp dụng các mẫu vào mô hình thiết kế UML.
CHƯƠNG 3:
QUY TRÌNH THỰC HIỆN KIỂM TRA KẾT QUẢ ÁP DỤNG MẪU VÀO MÔ HÌNH THIẾT KẾ UML
3.1. Giới thiệu
Các mẫu thiết kế (Design Pattern) luôn thu hút được sự quan tâm cả trong kinh doanh lẫn nghiên cứu lý thuyết để đạt được mục tiêu tăng khả năng sử dụng lại các thiết kế. Các mẫu thiết kế không phải là một bản thiết kế hoàn chỉnh để có thể chuyển trực tiếp thành mã nguồn, mà nó là một bản mô tả hay một mẫu mô tả việc giải quyết vấn đề có thể sử dụng được trong nhiều trường hợp khác nhau. Các mẫu thiết kế hướng đối tượng điển hình phải chỉ ra các mối quan hệ và tương tác giữa các lớp hoặc đối tượng, mà không cần phải xác định xem các lớp và các đối tượng ứng dụng cụ thể của nó. Cấu trúc của mẫu thiết kế rất rõ ràng và có khả năng sử dụng lại rất cao. Vì vậy, việc sử dụng các mẫu thiết kế là một sự lựa chọn tốt để cải tiến hoặc tinh chế thiết kế phần mềm. Áp dụng mẫu bằng cách tích hợp cấu trúc giải pháp của mẫu vào mô hình ban đầu. Tuy nhiên, chúng ta cần đảm bảo sự tích hợp đúng. Điều đó có nghĩa là mô hình phải thỏa mãn các tính chất cấu trúc của mẫu và bảo toàn hành vi của mô hình bàn đầu.
Trong chương này, chúng tôi sẽ trình bày về quy trình thực hiện kiểm tra kết quả áp dụng mẫu vào mô hình thiết kế UML. Hiện nay, có rất nhiều mẫu thiết kế, và tôi xin giới thiệu một số mẫu thiết kế được sử dụng khá thông dụng và mang lại hiệu quả cao, đó là mẫu Union Pattern và mẫu Composite Pattern.
3.2. Mẫu Union Pattern (UP)
3.2.1. Giới thiệu
Mẫu Union Pattern là một mẫu có cấu trúc mô tả mối quan hệ thừa kế giữa lớp cha và lớp con của nó. Lớp cha là lớp ảo đại diện cho tập hợp các lớp con. Mục tiêu của Union Pattern hướng tới hai lợi ích của thiết kế hướng đối tượng là
vì vậy, nó mô tả những khía cạnh bất biến hay những gì là chung nhất của tất cả các phần tử tập hợp lớp con của nó. Các lớp con cụ thể khác với các lớp khác về một số hành vi. Vì vậy mà chúng mô tả các khía cạnh thay đổi của vấn đề.
Tại bất kì thời điểm nào, chương trình sử dụng các lớp trong trong mẫu Union Pattern sẽ thực thi ở mức thấp hơn, hay là ở mức cụ thể hơn, hoặc ở mức mức trừu tượng thấp hơn trong mô hình có nhiều mức trừu tượng khác nhau. Các mã nguồn làm việc tại mức trừu tượng của lớp cha là mã không thay đổi. Nó có khả năng làm việc với bất kì một thể hiện của lớp cụ thể nào bởi vì nó chỉ xử lý các hành vi bất biến của lớp cha. Tất cả các hành vi thực tế của hệ thống chính là hành vi bất biến của lớp trừu tượng và thêm vào những hành vi được những thể hiện ở lớp cụ thể, được sử dụng và cung cấp một cách có tính đa hình. Union Pattern sử dụng các khái niệm cơ bản trong thiết kế hướng đối tượng như là Tính thừa kế, Tính đa hình, Tính trừu tượng, Sự đóng gói với mục đích làm mạnh hơn, khả chuyển và tính hiệu quả của hệ thống. Hiện nay, biểu đồ lớp UML của mẫu thiết kế Union Pattern thường có dạng:
Hình 3.1. Mô hình của mẫu Union Pattern.
3.2.2. Các tính chất cấu trúc cần đảm bảo
o Hai hoặc nhiều lớp con: Lớp con có thể là lớp ảo, trong trường hợp đó, nó sẽ biểu diễn tầng trìu tượng khác nhau.
o Một lớp cha trìu tượng: biểu diễn sự trìu tượng hóa tất cả các lớp con. Một lớp cha không có thể hiện cụ thể bởi vì nó không mô tả bất cứ thực thể tồn tại riêng biệt nào. Các phương thức của lớp cha có thể là trìu tượng (các hành vi biến đổi được định nghĩa trong các lớp con) hoặc có thể là cụ thể (giữ nguyên các hành vi đó).
Tóm lại, kết quả của việc ứng dụng mẫu Union Pattern là một mô hình thiết kế bao gồm một lớp cha trìu tượng và các lớp con. Lớp cha trìu tượng có cả phương thức cụ thể thực thi những hành vi bất biến của hệ thống và các phương thức trìu tượng mô tả hành vi biến đổi của hệ thống và được khai triển trong các lớp con cháu của nó. Các lớp con có các phương thức cụ thể thực thi các hành vi biến đổi của hệ thống và mô tả tính đa hình của hệ thống.
3.2.3. Một số trường hợp áp dụng sai mẫu Union Pattern
Ta có ví dụ sau, áp dụng mẫu Union Pattern với biểu đồ lớp sau: