CHƯƠNG 1 : PHÁT TRIỂN PHẦN MỀM HƯỚNG MÔ HÌNH
2.2. Chuyển đổi mô hình trong UWE
2.2.2. Chuyển đổi từ mơ hình uc ầu, nội dung sang mơ hình điều hướng
Mục tiêu của mơ hình điều hướng để xác định khả năng điều hướng thông qua các nội dung của một ứng dụng Web, tức là xác định một giao diện điều hướng tĩnh của nội dung, để xác định một giao diện điều hướng tĩnh của nội dung, các nút đại diện cho các thơng tin từ các mơ hình nội dung và các liên kết thể hiện các đường dẫn điều hướng giữa các nút. Như vậy, các yếu tố cơ bản trong mơ hình điều hướng là các nút điều hướng và các liên kết.
Từ mơ hình nội dung ta chuyển đổi sang mơ hình điều hướng với các thành phần cơ bản, để từ đó loại bỏ bớt và bổ sung thêm các thành phần khác nhằm hồn thiện mơ hình. Việc đặc tả mơ hình điều hướng bắt buộc phải tuân thủ chặt chẽ các quy tắc chuyển đổiđã đề ra, vì dữ liệu từ các mơ hình này sẽ được dùng cho việc chuyển đổi. Mơ hình điều hướng thểhiện các chức năng của ứng dụng và có thể được chuyển đổi tự động tạo ra mơ hình điều hướng từ mơ hình u cầu và các mơ hình nội dung (Hình 2.8) [1].
Chuyển đổi RequirementsAndContent2Navigation [1]
Quy tắc ContentClass2NavigationClass
Mỗi lớp nội dung là đối tượng của một Web use case hoặc đích của Web use case, trả về bởi helper isRelevantForNavigation, được ánh xạ tới lớp điều hướng với tên giống nhau. Thêm vào đó, một tham chiếu được phân cơng tới lớp nội dung tương ứng. Quy tắc như sau.
rule ContentClass2NavigationClass {
from c : UWE!Class ( c.is RelevantForNavigation() )
to tc : UWE!Class ( … ), -- target for copying source element nc : UWE!NavigationClass
( name <- c.name, contentClass <- tc, ownedAttribute <- c.ownedAttribute->collect( p | thisModule.resolveTemp( p, 'np' ) ), … ), … } Quy tắc Property2NavigationProperty
Mỗi sở hữu nội dung mà không phải là một phần của association sẽ được ánh xạ tới một sở hữu điều hướng. Quy tắc như sau:
rule Property2NavigationProperty {
from p : UWE!Property ( p.oclIsTypeOf( UWE!Property ) and
p.class_.isRelevantForNavigation() and p.association.oclIsUndefined() ) to tp : UWE!Property ( … ), -- ta rget for copying source element
np : UWE!NavigationProperty ( name <- p.name, class_ <- p.class_, type <- p.type, contentProperties <- Sequence { p }, … ) } Quy tắc AssociationProperty2NavigationLink
Mỗi sở hữu của một association được sở hữu bởi một lớp nội dung được ánh xạ tới liên kết điều hướng và hai sở hữu điềuhướng tương ứng. Một điều kiện thêm vào là navigation use case tương ứng tồn tại trong mơ hình u cầu. Các association một chiều được ánh xạ tới một liên kết điều hướng và các association hai chiều đến hai liên kết điều hướng.
rule AssociationProperty2NavigationLink {
from p : UWE!Property (
if p.class_.oclIsTypeOf( UWE!Class ) then p.oclIsTypeOf( UWE!Property ) and
not p.association.oclIsUndefined() and p.class_.useCase->exists( uc |
uc.oclIsKindOf( UWE!Navigation ) and uc.target() = p.type ) else false endif )
to tp : UWE!Property ( … ), -- ta rget for copying source element nl : UWE!NavigationLink ( … ), nps : UWE!Property ( association <- nl, owningAssociation <- nl, type <- p.class_, … ), np : UWE!NavigationProperty ( name <- p.name, class_ <- p.class_, type <- p.type, association <- nl, contentProperties <- Set { p }, … ) }
2.2.3. Chuyển đổi sang mơ hình xử lý
Mơ hình xử lý (cịn gọi là mơ hình nhiệm vụ) xuất phát từ lĩnh vực giao diện người máy [84]. Các thành phần «processClass» ở mơ hình điều hướng sẽ được thể hiện rõ hơn bởi mơ hình xử lý. Chúng được đặc tả bởi biểu đồ hoạt động với các Action mà người dùng có thể thực hiện trong ứng dụng web.
Các mơ hình điều hướng của một ứng dụng Web miêu tả cấu trúc thông tin tĩnh cịn Mơ hình xử lý diễn tả ý động của ứng dụng Web.[1]
Chuyển đổi sang mơ hình xử lý [1]
Việc chuyển đổi sang mơ hình xử lý nhằm nâng cao mơ hình định hướng, bằng cách thêm các lớp xử lý và liên kết xử lý đối với việc tích hợp xử lý.
Quy tắc Menu2IntegratedMenu
Mỗi Web process use case từ mơ hình yêu cầu được ánh xạ tới lớp xử lý trong mơ hình điều hướng được tích hợp. Một liên kết xử lý kết nối với menu tương ứng tới lớp nội dung của Web process use case để tạo ra lớp xử lý. Một liên kết xử lý liên tục được tạo ra cho đích bắt buộc của Web process use case.
rule Menu2IntegratedMenu {
from nc : UWE!Menu (
nc.contentClass.useCase->exists( uc | uc.oclIsKindOf( UWE!WebProcess ) ) ) using
{
wps : Sequence( UWE!WebProce ss ) = nc.contentClass.useCase-> select( uc | uc.oclIsKindOf( UWE!WebProcess ) )->asSequence(); wpsWithTarget : Sequence( UWE!W ebProcess ) = wps->select( wp | not wp.target.oclIsUndefined() );
wpsWithoutTarget : Sequence( UWE! WebProcess ) = wps->select( wp | wp.target.oclIsUndefined() );
wpsOrdered : Sequence( UWE!WebProcess ) = wpsWithTarget-> union( wpsWithoutTarget );
}
to tnc : UWE!Menu ( … ), -- tar get for copying source element pc : distinct UWE!ProcessClass foreach ( wp in wpsOrdered ) (
name <- let n : String = wp.name.regexReplaceAll( ' ', '' ).firstToUpper() in if UWE!WebProcess.allInstances()->select( uc |
uc.name.regexReplaceAll( ' ', '' ).firstToUpper() = n )->size() > 2 then nc.getTraceSource( 'NavigationClass2Menu' ).name else '' endif + n, …
pl : distinct UWE!ProcessLink foreach ( wp in wpsOrdered ) (
… ),
epl : distinct UWE!ProcessLink foreach ( wp in wpsWithTarget ) (
… ), …
}
2.2.4. Chuyển đổi từmơ hình điều hướng, xử lý sang mơ hình trình bày
Mơ hình trình bày định nghĩa từ các lớp của mơ hình xử lý và mơ hình điều hướng. Mơ hình trình bày đặc tả chính xác các thành phần giao diện người dùng và xác định cụ thể cấu trúc của ứng dụng web mà các mơ hình điều hướng, xử lý, khơng thể hiện được…
Chuyển đổi AvigationAndProcess to Presentation [1]
Lớp trình bày tạo ra bởi mỗi node trong mơ hình điều hướng và mỗi lớp dữ liệu xử lý. Một sở hữu xử lý tương ứng được tạo ra bởi mỗi thuộc tính cùng với kiểu của thành phần giao diện người dùng.
Rule NavigationClass2PresentationClass
Với mỗi lớp điều hướng, một lớp trình bày được tạo ra bởi quy tắcnày. Hơn nữa, với mỗi thuộc tính của lớp điều hướng cùng với một kiểu datatype thì một thành phần giao diện người dùng văn bản được tạo ra. Đối với mỗi liên kết, một thành phần giao diện người dùng cố định được tạo ra.
rule NavigationClass2PresentationClass {
from nn : UWE!NavigationClass (
not nn.isAbstract and nn.oclIs TypeOf( UWE!NavigationClass ) ) to tnn : UWE!NavigationClass ( … ), -- target for copying source element pc : UWE!PresentationClass
( …
),
textUis : distinct UWE!Text foreach ( p in nn.allOwnedAttribute()-> select( p | p.type.oclIsKindOf( UWE!DataType ) ) )
(
name <- p.name.firstToUpper(), …
),
anchorUis : distinct UWE!Anchor foreach ( p in nn.allOwnedAttribute()-> select( p | p.association.oclIsKindOf( UWE!Link ) ) )
( name <- p.type.name, … ), … } Quy tắc Menu2PresentationClass
Với mỗi menu, một lớp trình bày được tạo ra bằng quy tắc này. Với mỗi liên kết một thành phần giao diện người dùng cốđịnh được tạo ra.
rule Menu2PresentationClass {
from nn : UWE!Menu ( not nn.isAbstract )
to tnn : UWE!Menu ( … ), -- target for copying source element pc : UWE!PresentationClass
( … ),
anchorUis : distinct UWE!Anchor foreach ( p in nn.allOwnedAttribute()-> select( p | p.association.oclIsKindOf( UWE!Link ) ) )
( name <- p.type.name, … ), … } Quy tắc Index2PresentationClass
Với mỗi Index, một lớp trình bày được tạo ra bằng quy tắc này. Ngoài ra, một thành phần giao diện người dùng cốđịnh được tạo ra bởi các liên kết ngoài.
rule Index2PresentationClass {
from nn : UWE!Index
to tnn : UWE!Index ( … ), -- ta rget for copying source element pc : UWE!PresentationClass ( … ), anchorUi : UWE!Anchor (
name <- nn.outLinks-> first().target.name, …
), … }
Quy tắc ProcessClass2PresentationClass
Quy tắc này chuyển đổi lớp xử lý thành lớp trình bày. Đối với tất cả các thuộc tính của lớp xử lý cùng với một kiểu nguyên thủy, một thành phần đầu vào văn bản được tạo ra. Các thuộc tính với kiểu enumeration được ánh xạ tới một thành phần đầu vào enumeration và tất cả các thuộc tính được ánh xạ tới thành phần đầu vào selection, đối với sở hữu trình bày là tương ứng tới quan hệ thành phần giữa việc tạo ra lớp trình bày và tạo ra lớp giao diện người dùng.
rule ProcessClass2PresentationClass {
from nn : UWE!ProcessCla ss ( nn.inLinks->isEmpty() )
to tnn : UWE!ProcessClass ( … ), -- target for copying source element pc : UWE!PresentationClass
( … ),
textInputUis : distinct UWE!TextInput foreach ( p in nn.allOwnedAttribute()-> select( p | p.type.oclIsKindOf( UWE!PrimitiveType ) ) ) ( name <- p.name.firstToUpper(), … ),
p in nn.allOwnedAttribute()->select( p | p.type.oclIsKindOf( UWE!Enumeration ) ) ) ( name <- p.name.firstToUpper(), … ),
selectionUis : distinct UWE!Selection foreac h ( p in
nn.allOwnedAttribute()->select( p | p.type.oclIsTypeOf( UWE!Class ) ) ) ( name <- p.name.firstToUpper(), format <- p.type.name, … ), … }
2.3. Phát triển quy tắc chuyển đổi mơ hình tích hợp ràng buộc OCL
Chuyển đổi mơ hình là trung tâm của kỹ thuật phần mềm hướng mơ hình. Chuyển đổi mơ hình là q trình, trong đó một mơ hình là nguồn được chuyển thành một mơ hình khác – mơ hình đích, bằng cách sử dụng các quy tắc chuyển đổi nhất định. Trong phương pháp UWE, chuyển đổi mơ hình, giúp tự động hóa q trình phát triển ứng dụng Web. Dựa trên bộ quy tắc chuyển đổi, từ mơ hình yêu cầu sẽ chuyển đổi tự động thành các mơ hình nội dung, điều hướng, xử lý và trình bày. Từ đó, chuyển đổi sang mã nguồn, giúp giảm chi phí và nâng cao hiệu quả phát triển ứng dụng Web. Ngoài ra, trải nghiệm của người dùng đóng vai trị hết sức quan trọng trong sự thành công của ứng dụng Web. Trải nghiệm này bị ảnh hưởng bởi rất nhiều yếu tố, kiểm tra tính dữ liệu từ các form nhập liệu là một trong những yếu tố quan trọng nhất. Dữ liệu sau khi được kiểm tra có thể được sử dụng cho việc xử lý các nghiệp vụ của ứng dụng hoặc có thể được lưu vào cơ sở dữ liệu. Do tầm quan trọng của việc kiểm tra dữ liệu, nó phải được coi như một phần của phương pháp phát triển Web hướng mơ hình [11,19]. Vì vậy, việc tích hợp chuyển đổi ràng buộc OCL vào chuyển đổi mơ hình trong phát triển ứng dụng Web, theo phương pháp UWE là hết sức cần thiết.
Kỹ thuật hướng mơ hình giải quyết được sự phức tạp của nền tảng công nghệ khác nhau, bằng việc sử dụng các mơ hình như là tác nhân chính trong tồn bộ vịng đời phát triển ứng dụng, giảm sự phụ thuộc vào nền tảng cơng nghệ [3, 9, 13]. Khi có nền tảng mới ra đời thì ứng dụng mới sẽ được chuyển đổi tự động từ các mơ hình để tương thích với nền tảng mới. Các ứng dụng Web bao gồm nhiều thành phần khác nhau có thể được cung cấp bởi những nhà phát triển khác nhau, với nền tảng công nghệ khác
nhau, nên việc sử dụng các kỹ thuật phát triển hướng mơ hình cho các ứng dụng Web đặc biệt hữu ích [2, 5, 11]. Trong đó, UWE là kỹ thuật phát triển ứng dụng web hoàn chỉnh và được sử dụng nhiều nhất trong kỹ thuật Web hướng mơ hình [1, 3,10]. Q trình phát triển của phương pháp UML-based Web Engineering (UWE [5] là phát triển từ quy trình thủ cơng, thơng qua quy trình chuyển đổi mơ hình bán tự động [5]. Do đó, cịn nhiều thành phần của mơ hình phải được điều chỉnh thủ cơng, làm cho việc phát triển ứng dụng Web tốn thời gian và chi phí.
Áp dụng những nguyên lý của MDA, mục tiêu tiếp cận của UWE là xây dựng những tập của CIM, PIM, và PSM như là kết quả của việc phân tích, thiết kế và cài đặt của q trình định hướng mơ hình. Mục đích giai đoạn phân tích là tập hợp được một tập các yêu cầu ổn định, các yêu cầu chức năng sẽ được mô tả lại bởi ý nghĩa của các mơ hình u cầu. Mơ hình u cầu bao gồm các ‘use cases’ chuyên biệt và các ‘class model’ cho ứng dụng Web. Giai đoạn thiết kế bao gồm việc xây dựng một loạt các mơ hình ở mức độ độc lập nền tảng. Sau đó các mơ hình thiết kế được chuyển đổi để thực hiện trên các nền tảng cụ thể [61].
Quy trình bắt đầu bằng mức mơ hình nghiệp vụ (CIM) định nghĩa một mơ hình yêu cầu. Các mơ hình thiết kế độc lập nền hệ thống (các PIM) được dẫn xuất từ mơ hình u cầu này. Tập các mơ hình thiết kế này biểu diễn các mối quan tâm khác nhau của các ứng dụng Web. Nó bao gồm nội dung (content), điều hướng (navigation), xử lý (process), trình bày (presentation).
Kỹ thuật nổi lên gần đây trong chuyển đổi mơ hình được sử dụng trong UWE là ATL và QVT [[4, 45, 65]. Để làm việc này, UWE được hỗ trợ bởi nhiều công cụ như: ArgoUWE, MagicUWE và UWE4JSF [62]. Một trong những công cụ thực hiện tốt cho công việc này là MagicUWE. [1] đã đề xuất một bộ quy tắc chuyển đổi mơ hình trong phương pháp UWEnhư sau:
- Mơ hình nội dung được tự động lấy từ các mơ hình u cầu, bằng cách áp dụng quy tắc Requirements2Content. Sau đó, kết quả của mơ hình nội dung được tinh chế bởi nhà phát triển bằng cách thêm vào các lớp, các thuộc tính, liên kết.
- Chuyển đổi từ mơ hình u cầu và nội dung sang mơ hình điều hướng: Mơ hình điều hướng thể hiện rõ nét tất cả các chức năng của ứng dụng. Có thể chuyển đổi tự động tạo ra một mơ hình điều hướng ban đầu, từ mơ hình u cầu và các mơ hình nội dung bằng quy tắc RequirementAndContent2navigation.
- Chuyển đổi sang mơ hình xử lý: Mơ hình xử lý được đặc tả bởi biểu đồ hoạt động, các Action mà người dùng có thể thực hiện trong ứng dụng web. Việc chuyển đổi sang mơ hình xử lý được thực hiện bằng quy tắc PrecessIntegration.
- Chuyển đổi từ mơ hình điều hướng, xử lý sang mơ hình trình bày: Thực hiện bằng quy tắc navigationAndProcess2Presentation.
- Mặc dù [1] đã đưa ra bộ quy tắc và công cụ MagicUWE để chuyển đổi mơ hình, nhưng nó mới chỉ dừng ở việc hỗ trợ cho nhà thiết kế các hoạt động tạo lập mơ hình, bằng cách sử dụng cấu hình UWE và tạo mơ hình bán tự động, Trong thực tế, vẫn còn nhiều thành phần của mơ hình mà nhà thiết kế phải vẽ lại thủ công và MagicUWE mới chỉ chủ yếu tập trung vào việc mở rộng công cụ với các yếu tố mơ hình hóa cho các ứng dụng.
Kế thừa các quy tắc chuyển đổi mơ hình đã được tích hợp trong cơng cụ MagicUWWE [1], luận án đề xuất bổ sung một số quy tắc chuyển đổi sang mơ hình xử lý và mơ hình trình bày, nhằm cải tiến, nâng cao hiệu quả chuyển đổi mơ hình UWE từ cơng cụ MagicUWE.
2.3.1. Giới thiệu phương pháp
Trong quá trình phát triển phần mềm người ta nhận ra rằng, chỉ với hệ thống ký hiệu trực quan trong UML thì khơng thể hiện được hết các khía cạnh của hệ thống phần mềm. Chính vì thế, OCL được xây dựng và phát triển với mục đích, bổ sung cho các đặc tả UML trở nên rõ ràng và chính xác hơn. Thêm vào đó, OCL là ngơn ngữ chuẩn, được chấp nhận rộng rãi để viết các ràng buộc trong các mô hình UML; ví dụ: có thể viết ràng buộc cho các thuộc tính trong biểu đồ lớp, các bất biến (invariants) của các trạng thái, các bảo vệ (guards) của sự chuyển đổi các trạng thái, ràng buộc trong biểu đồ tuần tự, tiền và hậu điều kiện của các phương thức. OCL giúp khắc phục những thiếu sót và hạn chế của các mơ hình, nó giúp biểu diễn các đặc tả, các ràng buộc mà nhiều khi mơ hình khơng thể biểu diễn hết được. Do vậy, đề tài đã chọn theo hướng tích hợp OCL vào các mơ hình nhằm giúp cho việc chuyển đổi tự động giữa các mơ hình hiệu quả hơn.
Với phương pháp tiếp cận của luận án, phát triển ứng dụng web dựa trên việc mô tả mơ hình u cầu, sau đó chuyển đổi tự động sang các mơ hình khác trong UWE: mơ hình nội dung, điều hướng, xử lý, trình bày. Bản thân các mơ hình trong kỹ thuật UWE tuy có cấu trúc khác biệt và được định nghĩa thêm một số thành phần mới so với các mơ hình UML khác, nhưng bản chất vẫn là các thành phần của UML. Vì vậy, việc áp dụng ràng buộc OCL vào mơ hình u cầu và thực hiện chuyển đổi mơ hình là một hướng mở rộng cho phương pháp này.
Trong mục 2.2 đã trình về q trình chuyển đổi từ mơ hình, các thành phần ở mơ hình đích sẽ được chuyển sang các thành phần tương ứng ở mơ hình nguồn. Ví dụ như user action thành process class, pin thành các thuộc tính của class và tham số của phương thức validate. Khi pin đó cần phải kiểm tra tính hợp lệ của giá trị, thì một hoặc một số ràng buộc OCL sẽ được khai báo và gán cho pin đó. Vậy yêu cầu đặt ra là, sau chuyển đổi mơ hình, tạo ra các thành phần đích tương ứng với thành phần