Luận văn thạc sĩ Khoa học máy tính: Áp dụng đặc tả hình thức vào mô hình đặc tả yêu cầu phần mềm I*

Nghiên cứu, phân tích và đánh giá các phương pháp tính toán độ tương tự dựa trên đặc trưng và dựa trên logic khi biểu diễn mục tiêu của mô hình i* dưới dạng biểu diễn logic, cũng như đề

GIỚI THIỆU

Lý do và mục đích nghiên cứu

Ngày nay, ứng dụng công nghệ thông tin vào trong công việc ngày càng nhiều, từ đó nhu cầu phát triển phần mềm cũng tăng lên Trong giai đoạn đầu của phát triển phần mềm là giai đoạn phân tích yêu cầu, các yêu cầu về phần mềm cần xây dựng phải được đặc tả một cách đầy đủ để có thể tiến hành thiết kế và xây dựng phần mềm cho phù hợp

Các đặc tả này có thể ở dưới các dạng phi hình thức (informal) như các biểu đồ, văn bản hoặc hình thức (formal) như các biểu thức toán mô tả yêu cầu Tính chính xác và hữu dụng của các đặc tả ở bước này rất quan trọng vì nó phải mô tả được phần mềm cần xây dựng, giúp các nhà phát triển phần mềm có các quyết định đúng đắn trong thiết kế và hiện thực phần mềm, cũng như giúp kiểm chứng về chất lượng sản phẩm làm ra

Các nghiên cứu về đặc tả hình thức đã bắt đầu từ rất sớm và đã đạt được một số thành công nhất định Tuy nhiên, các nghiên cứu gần đây đã chỉ ra những điểm còn yếu của phương pháp này như là chi phí (thời gian và nhân lực) rất cao, mức trừu tượng đặc tả thấp và chưa phù hợp với các yêu cầu phát triển phần mềm nhanh chóng như hiện nay Một số nghiên cứu khác đã chỉ ra rằng, phương pháp này cần phải được cải tiến theo hướng tăng tính tích hợp, tăng mức độ trừu tượng đặc tả và chú tâm tạo ra các kỹ thuật hạng nhẹ, chi phí (thời gian và nhân lực) thấp Mặc dù có nhiều nhóm nghiên cứu về lĩnh vực Công nghệ phần mềm ở Việt nam, nhưng các nghiên cứu chuyên về đặc tả hình thức và ứng dụng vào trong thực tiễn hiện nay còn chưa phát triển nhiều

Các phương pháp đặc tả hình thức có ưu điểm rõ rệt về nền tảng lý thuyết để đảm bảo tuyệt đối tính đúng đắn của một hệ thống, để có áp dụng trong công nghiệp phần mềm Tuy nhiên, việc đặc tả thường phức tạp, nặng về toán học cần các chuyên gia về phương pháp hình thức, một số thành phần trong hệ thống khó có thể mô tả bằng ngôn

Trang 2 ngữ hình thức Hơn nữa khách hàng thường không thích các đặc tả toán học nên không hiểu hiểu được các đặc tả này, do đó chúng ta cần để che dấu bớt các rối rắm toán học và tăng cường các công cụ hổ trợ trong phân tích yêu cầu Ngoài ra, đặc tả hình thức cần được nâng từ mức thiết kế chức năng đến mức trừu tượng trong bước phân tích yêu cầu (requirement engineering), cũng như tính tích hợp (integration) của các đặc tả hình thức trong vòng đời phát triển phần mềm

Trong những năm gần đây, UML trở thành một ngôn ngữ chuẩn để mô hình hóa các yêu cầu phần mềm và thiết kế Tuy nhiên, ở giai đoạn đầu của việc đặc tả yêu cầu thì ngôn ngữ UML thường chú trọng đến việc biểu diễn thông tin của các tác nhân và sự tương tác của tác nhân với các usecase, còn mối quan hệ giữa tác nhân với tác nhân và usecase với usecase thỡ lại sơ xài, chủ yếu với 3 mối quan hệ: Generalization, ôIncludeằ and ôExtendằ Ngoài ra, cũng cũn một vấn đề khỏc là việc phõn ró một usecase thành một hệ thống sub các usecase cũng là khó khăn trong UML

Ngôn ngữ mô hình i* là ngôn ngữ mô hình thích hợp cho việc mô hình hóa yêu cầu ở giai đoạn đầu và giúp hiểu được các vấn đề của đặc trưng miền [4] Ngược lại với hướng tiếp cận UML khi mà sơ đồ Usecase chỉ bao gồm hàm mục tiêu (tác nhân nào thực hiện những hành động nào – cụ thể trong phần mềm), ngôn ngữ mô hình i* có cả hướng tác nhân và hướng mục tiêu Ngôn ngữ mô hình i* trả lời câu hỏi: who và why, không trả lời câu hỏi what Ngôn ngữ mô hình i* còn cho phép mô hình cả hai tình huống là: as-is và to-be Ngoài ra, ngôn ngữ mô hình i* cung cấp nhiều mức độ phân tích: ability (khả năng), workability (khả năng làm việc), viability (tính khả thi) và believability (số lượng khả tin)

Việc mô hình hóa ở giai đoạn đầu, ngoài việc chọn được một ngôn ngữ mô hình thích hợp thì việc tái sử dụng lại các mô hình đã có cũng là một vấn đề cần quan tâm Như thế nào mà người phân tích yêu cầu khi thực hiện các bước phân tích thì có được những bước gợi ý là đã có một mô hình tương tự để cho việc phân tích được diễn ra

Trang 3 nhanh hơn và kết quả phân tích qua thời gian ngày càng được cải thiện do tận dụng lại được các mô hình phân tích trước đó.

Mục tiêu và giới hạn luận văn

Ngôn ngữ mô hình i* là một ngôn ngữ mô hình hướng mục tiêu Trong một tác nhân, ta có thể thấy nó hướng tới mục tiêu nào và để đạt được mục tiêu đó thì nó cần có những công việc, tài nguyên hay những mục tiêu con nào Trong luận văn, sẽ tập trung vào việc biểu diễn mục tiêu trong mô hình i* dưới dạng biểu diễn logic

Khi đã có được biểu diễn logic các mục tiêu trong mô hình i*, vấn đề thứ hai là làm sao có thể tính toán độ tương tự giữa các mô hình i* dựa trên các biểu diễn này Luận văn sẽ nghiên cứu và đánh giá phương pháp tính độ tương tự dựa vào logic trên để có thể thấy được các ưu và khuyết điểm của phương pháp, từ đó đề nghị bổ sung một phương pháp/giải thuật hỗ trợ khác

Vấn đề thứ ba là việc lưu trữ các biểu diễn này cũng như các biểu diễn đã có trước đó Có nhiều cách để lưu trữ như dùng các hệ cơ sở dữ liệu hay định nghĩa một cấu trúc lưu trữ dạng tập tin, nhưng các cách trên phải đảm bảo được việc có thể hiển thị lại mô hình đã vẽ dưới dạng đồ họa và các đặc tả đã được chuyển đổi từ mô hình

Tóm lại, đề tài sẽ tập trung biểu diễn mục tiêu trong mô hình i* dưới dạng biểu diễn logic Nghiên cứu phương pháp/giải thuật tính độ tương tự giữa các biểu diễn logic trên, các giải thuật đề nghị bổ sung để tăng độ chính xác cho phương pháp tính độ tương tự dựa trên logic và xây dựng thư viện lưu trữ các đặc tả

Hình 1.1 cho thấy quy trình tiếp cận của luận văn, luận văn sẽ tập trung giải quyết phần 2.1 và 2.2 là tính toán độ tương tự để có thể gợi ý cho người phân tích yêu cầu và xây dựng thư viện lưu trữ

Kết quả đạt được của đề tài là một đóng góp cho kỹ thuật sử dụng đặc tả hình thức trong việc biểu diễn và tính độ tương tự giữa các mục tiêu của mô hình i* Thấy được

Trang 4 ưu và khuyết điểm của kỹ thuật này trong việc biểu diễn mục tiêu của mô hình i* và cách thức xây dựng một thư viện lưu trữ để có thể sử dụng lại các mô hình về sau

Hình 1.1: Mô phỏng quy trình tiếp cận của của đề tài

Cấu trúc của luận văn

Các phần còn lại của luận văn được tổ chức như sau:

Chương 2 – Các nghiên cứu liên quan: luận văn sẽ trình bày các công trình và nghiên cứu liên quan về ngôn ngữ mô hình i*, các phương pháp tính độ tương tự dựa trên logic giữa các Web Service, nhận xét về phương pháp tính độ tương tự trên để có thể áp dụng vào bài toán của luận văn

Chương 3 – Cơ sở lý thuyết: luận văn sẽ trình bày các vấn đề về cơ sở lý thuyết về ngôn ngữ mô hình i*, các khái niệm và định nghĩa của phương pháp đặc tả hình thức, khái niệm về đồ thị con đẳng cấu để giải quyết khuyết điểm của việc sử dụng đặc tả hình thức khi biểu diễn mục tiêu của mô hình i*

Chương 4 – Mô hình hóa bài toán: luận văn sẽ trình bày cách thức biểu diễn mục tiêu trong mô hình i* dưới dạng biểu diễn logic Nghiên cứu, đánh giá phương pháp tính độ tương tự dựa trên logic cho mục tiêu trong mô hình i* Đồng thời đề xuất một giải thuật bổ sung để hỗ trợ giải quyết khuyết điểm của phương pháp tính độ tương tự dựa trên logic

Chương 5 – Case studies: để có thể hiểu rõ hơn về cách thức biểu diễn mục tiêu trong mô hình i* và các bước tính toán độ tương tự giữa các mô hình để hệ thống có thể gợi ý cho người phân tích yêu cầu, luận văn sẽ trình bày một case study nhỏ với các trạng thái thay đổi độ tương tự và kết quả gợi ý khi người phân tích yêu cầu vẽ mô hình i* ở từng bước

Chương 6 – Hiện thực và thực nghiệm: phần hiện thực luận văn sẽ trình bày phần hiện thực hệ thống Kiến trúc của hệ thống gồm những thành phần nào, cách xây dựng cơ sở dữ liệu lưu trữ Phần thực nghiệm, luận văn sẽ trình bày các bộ dữ liệu kiểm thử và kết quả thực nghiệm So sánh các kết quả thực nghiệm giữa các phương pháp đề xuất

Chương 7 – Kết luận: trình bày các kết quả đạt được và chưa đạt được của luận văn, các vấn đề khó khăn khi thực hiện luận văn, và đề xuất hướng nghiên cứu tiếp theo trong tương lai.

CÁC NGHIÊN CỨU LIÊN QUAN

Ngôn ngữ mô hình i*

Ngày nay cũng có rất nhiều nghiên cứu và ứng dụng sử dụng ngôn ngữ mô hình i* Theo MIT Press [7], quyển sách “Social Modeling for Requirements Engineering” của tác giả Eric Yu [23] mô tả một cách tiếp cận dựa trên việc mô hình hóa dùng ngôn ngữ mô hình i* hay còn gọi là khung thức i* (i* framework) Cách tiếp cận này là một cách tiếp cận mới trong thách thức của việc lấy yêu cầu phần mềm, dựa trên mô hình hóa và phân tích các mối quan hệ giữa các bên liên quan, cũng như các mục tiêu cần đạt được, các nhiệm vụ cần được thực hiện và các tài nguyên cần được trang bị

Các công cụ để thiết kế và trừu tượng hóa mô hình i* đã được phát triển khá nhiều như: openOME [2], J-PRIM [3], Tagoon+ [1], … hay Visio của Mircosoft Các công cụ như openOME, J-PRIM cho phép người phân tích yêu cầu vẽ các mô hình hướng mục tiêu qua ngôn ngữ mô hình i*, cho xuất ra định dạng *.istarml là một chuẩn lưu trữ chung để trao đổi mô hình i* giữa các công cụ khác nhau Tagoon+ là một công cụ phát triển trên nền Java cho phép tích hợp mô hình i* vào Ontology, với đầu vào là tập tin *.istarml, đầu ra là tập tin *.owl Để tích hợp vào Ontology ngoài chuẩn đầu vào là tập tin iStarML thì các tập tin này cần được mở rộng với thuộc tính “sannotation” để lưu trữ các chú thích ngữ nghĩa cho mỗi phần tử mô hình

Trước một số lượng lớn các nghiên cứu cũng như các công cụ đã được xây dựng ở trên, ta thấy được i* là một ngôn ngữ mô hình thích hợp cho việc phân tích yêu cầu ở giai đoạn đầu

Tuy nhiên, công cụ nêu trên chỉ cho phép tích hợp nhưng chưa cho phép kiểm tra, đánh giá mô hình i* cũng như chưa có một cở sở dữ liệu các mô hình đã được đặc tả trước đó, hay cung cấp một cách thức để tính toán độ tương tự giữa các mô hình i* đã có để từ đó có thể tìm kiếm/gợi ý cho người phân tích yêu cầu các mô hình tương tự Các công cụ chỉ tập trung nhiều vào việc cho phép người thiết kế vẽ ra mô hình i* hay nổi bật nhất là công cụ Tagoon+ cho phép tích hợp mô hình i* vào Ontology như đã nêu ở trên, nên việc hướng tới một phương pháp tính toán độ tương tự giữa các mô hình i* cũng là một hướng tiếp cận mới và sẽ có đóng góp tốt cho ngôn ngữ mô hình hướng mục tiêu nói chung và ngôn ngữ mô hình i* nói riêng và đóng góp một cách áp dụng đặc tả hình thức vào một bài toán cụ thể

Hình 2.1: Tổng quan kiến trúc của công cụ Tagoon+

Biểu diễn logic của Web Service

Có nhiều các để biểu diễn các bài toán, biểu diễn logic là một trong số các phương pháp Theo [17], một web service có thể được bằng logic qua định nghĩa bằng các đặc tính input và output như sau:

- N là tên duy nhất của web service

- P là tiền điều kiện phải được thỏa mãn khi thực thi web service

- E là biểu diễn kết quả (hay hậu điều kiện) sau khi web service thực thi

- Q là tập các thuộc tính về chất lượng, mỗi thuộc tính gồm cặp giá trị nam/value, ví dụ {respTime =3} (thời gian phản hồi = 3)

Các input và output của web service được biểu diễn như sau:

WS  fin  fout  fin-1  …  fin-m  fout-1  …  fout-m trong đó:

- f in là biểu diễn logic thể hiện thuộc tính đầu vào của hàm và các tiền điều kiện

- fout là biểu diễn logic thể hiện thuộc tính đầu ra của hàm và hiệu quả

Ví dụ: WS1 là web service HotelReservationService WS1 nhận vào Hotel và Dates, sau đó trả về thông tin HotelReservation

- fout: HotelReservation hay: WS  Hotel  Dates  HotelReservation

Hình 2.2 biểu diễn cách một web service được chuyển sang biểu diễn logic Với

ID, Inputs, Preconditions, Outputs, Effects của web service lần lượt được chuyển sang Name, Left, Right của biểu diễn logic

Trong công thức 𝐿𝑒𝑓𝑡 → 𝑅𝑖𝑔ℎ𝑡 nếu một vế nào đó không có thành phần thì chúng ta xem vế đó là true Ví dụ: WS  Hotel  Dates  true, với web service không có thành phần ở vé phải

Hình 2.2: Mapping giữa web service và biểu diễn logic

Bước chuyển đổi OWL-S sang biểu diễn logic

Theo [17], việc chuyển đổi từ OWL-S sang biểu diễn logic là quá trình rút trích thông tin về input, output, pre-condition và effect của web services, sau đó chuyển đổi chúng sang thành phần của biểu diễn logic Gọi WSP i là thông tin của web service ith và f i là biểu diễn logic được chuyển đổi Mỗi thành phần được chuyển đổi như sau:

- Tên của biểu diễn logic là ID của web service: 𝑛𝑎𝑚𝑒(𝑓 𝑖 ) = 𝑊𝑆𝑃 𝑖 𝐼𝐷

- Vế trái của biểu diễn logic là input và pre-condition của web service:

- Vế phải của biểu diễn logic là output và effect của web service:

Hình 2.3 mô tả cách chuyển đổi web service “SightseeingCity Service” sang biểu diễn logic Các thành phần input và pre-condition là Sightseeing và SightseeingPopular sẽ được rút trích và được vào vế trái của biểu diễn logic, kết quả đạt được sau khi thực thi web service trên sẽ là một City có những Sightseeing và SightseeingPopular trên

Kết quả chuyển đổi web service “SightseeingCity Service” sang biểu diễn logic: SightseeingCityService: Sightseeing  popular(Sightseeing) → City

Sau khi đã hoàn tất việc chuyển đổi một web service sang biểu diễn logic Bước tiếp theo là cần tính toán độ tương tự của hai web service, việc tính toán độ tương tự của tác giả được dựa trên ba tiêu chí: tính toán độ tương tự dựa trên đặc trưng, tính toán độ tương tự dựa trên Ontology , điểm hạn chế của hai cách tính độ tương tự trên từ đó đưa ra phương pháp tính toán độ tương tự dựa trên logic

Hình 2.3: Mô tả chuyển đổi web service sang mệnh đề logic

Độ tương tự của Web Service có ngữ nghĩa dựa trên logic

Theo [17], tác giả đề xuất cách so sánh dựa trên độ đo mới giữa hai web service mà được biểu diễn như hai công thức logic Độ đo của tác giả được phát triển từ các độ đo cổ điển như:

- Feature-based similarity: Tác giả rút trích các đặc trưng từ các công thức logic, dựa trên tính toán độ tương tự giữa chúng

- Logic-based similarity: cuối cùng là thể hiện logic được dùng cho tính toán độ tương tự Tác giả sử dụng “xấp xỉ-hơn” (over-approximation) để tính toán độ xấp xỉ của công thức gốc Ý tưởng là hai công thức có logic giống sẽ có độ tương tự cao hơn so với công thức gốc

2.4.1 Độ tương tự dựa trên đặc trưng Để tính toán độ tương tự giữa hai biểu diễn logic (mệnh đề logic), chúng ta xác định phần giống nhau (the common part) và phần khác nhau (the different part) của hai biểu diễn Phần giống nhau và phần khác nhau được định nghĩa như sau:

Phần giống nhau - Ta có hai mệnh đề logic f và g Phần chung C sẽ được định nghĩa như sau:

Với fi, gj là số hạng nguyên tử (atomic terms) trong f và g Đặt a là hệ số phần chung giữa f và g a = |C|

Ví dụ: Hai mệnh đề logic f1 và f13 f 1 = Dates  Hotel → HotelReservation f 13 = ơHotel  ơDates  City  HotelReservation

C = {Dates, Hotel, HotelReservation} a = |C| = |{Dates, Hotel, HotelReservation}| = 3

Phần khác nhau - Ta có 2 mệnh đề logic f và g Phần khác nhau D sẽ được định nghĩa như sau:

D = (f ∪ g)\C = ({∀f i ∈ f} ∪ {∀g j ∈ g})\C Với fi, gj là số hạng nguyên tử (atomic terms) trong f và g Đặt b là hệ số phần khác nhau giữa f và g b = |D|

Ví dụ: Hai mệnh đề logic f1 và f13 f 1 = Dates  Hotel → HotelReservation f 13 = ơHotel  ơDates  City  HotelReservation

2 Độ tương tự dựa trên đặc trưng (Feature-based similarity) - Ta có hai mệnh đề logic f và g Phần độ tương tự dựa trên đặc trưng (Sim Fe ) sẽ được tính toán theo công thức như sau:

Sim Fe (f, g) = a a + b Theo ví dụ trên ta sẽ có

2.4.2 Độ tương tự dựa trên Logic

Theo [17], dù tính toán độ tương tự dựa trên đặc trưng, kết hợp với Ontology nhưng vẫn chưa đạt hiệu quả cao khi dữ liệu có tính logic Do đó, có thể tối ưu hóa độ tương tự thêm bằng cách dựa trên logic Độ xấp xỉ hơn (over approximation) của 2 mệnh đề - Ta có 2 mệnh đề logic f1 và f2 Xấp xỉ hơn sẽ được định nghĩa như sau: f 12 = f 1  f 2 = f 1 in  f 2 in → f 1 out  f 2 out

Trong đó,  là toán tử xấp xỉ hơn (over approximation operator), f 12 được chứng minh theo Z3 [19] Độ tương tự web service dựa trên logic – Ta có hai web service WSA, WSB, fA, fB là hai biểu diển logic của WSA, WSB , fAB là độ xấp xỉ hơn của của hai WSA, WSB theo định nghĩa trên Độ tương tự của hai web service WSA, WSB sẽ được tính toán dựa trên công thức sau:

Sim Lo (WS A , WS B ) = Sem Fe (f A , f AB )

2 Trong đó, Sim Fe (f 1 , f 2 ) là độ tương tự dựa trên đặc trưng của f 1 , f 2

Dựa trên công thức trên độ tương tự của 2 web service sẽ được tính toán theo giải thuật 1 sau:

Giải thuật 1: Tính toán độ tương tự dựa trên logic của 2 web service

Input: cặp web service WS1, WS2

Output: Giá trị của độ tương tự dựa trên logic – S

1 Xây dựng biểu diễn logic của 2 web services f 1 , f 2

2 Tính toán độ xấp xỉ hơn f 12 của f 1 , f 2

3 Sử dụng Z3 để đơn giản hóa f 12

4 Tính toán phần giống nhau và phần khác nhau a, b theo định nghĩa trên của mỗi cặp f 1 − f 12 , f 2 − f 12

5 Tính toán độ tương tự dựa trên tính chất Sim Fe (f 1 , f 12 ) và Sim Fe (f 2 , f 12 )

6 Tính toán độ tương tự dựa trên logic từ độ tương tự dựa trên tính chất Sim Fe (f 1 , f 12 ) và Sim Fe (f 2 , f 12 )

Ví dụ: Ta có 3 mệnh đề logic sau

- f 3 = Hotel → City Độ xấp xỉ hơn được tính như sau:

- f 23 = f 2  f 3 = (City → Hotel )  (Hotel → City) = (City  Hotel →

- f 13 = f 1  f 3 = (Dates  Hotel → HotelReservation) (Hotel → City) (Dates  Hotel) Hotel → City  HotelReservation ơHotel  ơDates City  HotelReservation

- f 12 = f 1  f 2 = true Độ tương tự dựa trên tính chất:

3 Độ tương tự dựa trên logic:

- Sim Lo (WS 1 , WS 2 ) = Sem Fe (f 1 ,f 12 )

- Sim Lo (WS 2 , WS 3 ) = Sem Fe (f 2 ,f 23 )

- Sim Lo (WS 1 , WS 3 ) = Sem Fe (f 1 ,f 13 )

21 Ở chương này, luận văn đã trình bày các nghiên cứu liên quan về ngôn ngữ mô hình i* để thấy được điểm mạnh và sự thích hợp của ngôn ngữ môn hình này Và luận văn cũng trình bày về phương pháp biểu diễn một web service dưới dạng biểu diễn logic, cách tính toán độ tương tự dựa trên logic Đây là một hướng tiếp cận tốt có thể sử dụng cho bài toán áp dụng đặc tả hình thức vào mô hình đặc tả yêu cầu phần mềm i*.

CƠ SỞ LÝ THUYẾT

Đặc tả hình thức

Trong ngành khoa học máy tính, các phương pháp hình thức là các kỹ thuật toán học cho việc đặc tả, phát triển và kiểm định các hệ thống phần mềm và phần cứng Cách tiếp cận này đặc biệt quan trọng đối với các hệ thống cần có tính toàn vẹn cao, chẳng hạn hệ thống điều khiển lò phản ứng hạt nhân hay điều khiển tên lửa, khi an toàn hay an ninh có vai trò quan trọng, để góp phần đảm bảo rằng quá trình phát triển hệ thống sẽ không có lỗi [8] Đặc tả hình thức được viết bằng tập các ký pháp có các quy định về cú pháp (syntax) và ý nghĩa (sematic) rất chặt chẽ Đặc tả hình thức cũng có thể là dùng mô hình, sơ đồ để mô tả Mô hình hệ thống được câú trúc sử dụng các thực thể toán học như là các tập hợp và các thứ tự

 Thiết kế ở mức cao: Ngôn ngữ Alloy, UML

 Thiết kế ở mức nguồn: JML (Java Modeling Language) (Java), Dafny (C#), Krakatoa (Java/C), …

Ngôn ngữ mô hình Java JML là một ngôn ngữ mô hình theo phương pháp “thỏa thuận” hay còn gọi là phương pháp Design by contract (DBC) Ý tưởng chính của phương pháp này là một lớp hay một phương thức và khách hàng của nó có một thỏa thuận với nhau Khách hàng phải bảo đảm các điều kiện đầu vào và các phương thức này phải thỏa mãn được các yêu cầu của khách hàng JML là ngôn ngữ đặc tả hành vi, được sử dụng để đặc tả hành vi của các mô đun trong ngôn ngữ Java Các đặc tả của JML được thêm vào mã nguồn của Java dưới dạng các chú giải (annotation) bên trong các chú thích

(comment) Ngôn ngữ Java sẽ hiểu các chú thích là JML khi các chú thích có ký tự bắt đầu là ký tự “@” Ví dụ: //@ cho định dạng chú thích từng dòng và /*@

@*/ cho định dạng chú thích nhiều dòng

Ngoài JML, thì còn những ngôn ngữ mô hình khác như ngôn ngữ mô hình hướng đối tượng Cụ thể là SOFL (Structured Object-Oriented Formal Language), SOFL là ngôn ngữ đặc tả dựa trên mô hình hướng đối tượng Nó cung cấp một ngôn ngữ đặc tả tổng quát cho tất cả các bước từ giai đoạn thu thập yêu cầu, đến giai đoạn thiết kế và hiện thực phần mềm Các công cụ hỗ trợ cho ngôn ngữ SOFL cũng có khá nhiều như

SOFL Specification Creator là công cụ cho phép soạn thảo các đặc tả một cách trực quan

(kéo thả) và tự động sinh ra các cấu trúc khung của đặc tả và mô đun xử lý tương ứng

Hình 3.1: Ảnh chụp giao diện của công cụ SOFL Specification Creator

Hình 3.1 thể hiện lược đồ dòng dữ liệu điều kiện (CDFD – Condition Data Flow Diagram) biểu diễn các thành phần process tương tác với nhau qua dòng dữ liệu và sử dụng các kho dữ liệu (data store)

Hai ngôn ngữ JML và SOFL được nêu ở trên là hai ngôn ngữ ở mức nguồn, còn trong giai đoạn đầu của việc phân tích yêu cầu Các khái niệm, yêu cầu và mục tiêu cần đạt được vẫn còn ở đang ở mức trừu tượng, ở giai đoạn này UML là một ngôn ngữ mô hình phổ biến và đã được áp dụng rộng rãi Tuy nhiên UML thì lại chú trọng với việc tác nhân nào thực hiện những hành động cụ thể nào ở trong phần mềm, và khi muốn phân rã các mô hình UML như sơ đồ UseCase cũng là một vấn đề khó khăn Ngôn ngữ mô hình i* là ngôn ngữ mô hình hướng mục tiêu và cả hướng tác nhân có thể đáp ứng được yêu cầu trên.

Ngôn ngữ mô hình i* (iStar)

Khung thức i* là một khung thức hoạt động theo mô hình hướng tác nhân (agent- modeling) hay hướng mục tiêu (goal-modeling), bao gồm các khái niệm như actor, role, agent, position, và các nguyên nhân về chúng

Tích hợp trong khung thức i* là ngôn ngữ mô hình i*, là ngôn ngữ mô hình thích hợp cho việc mô hình hóa yêu cầu ở giai đoạn đầu và giúp hiểu được các vấn đề của đặc trưng miền Ngược lại với hướng tiếp cận UML khi mà sơ đồ UseCase chỉ bao gồm hàm mục tiêu (tác nhân nào thực hiện những hành động nào – cụ thể trong phần mềm), ngôn ngữ mô hình i* có cả hướng tác nhân và hướng mục tiêu Ngôn ngữ mô hình i* trả lời câu hỏi: who và why, không trả lời câu hỏi what Ngôn ngữ mô hình i* còn cho phép mô hình hóa cả hai tình huống là: as-is và to-be Ngoài ra, ngôn ngữ mô hình i* cung cấp nhiều mức độ phân tích: ability (khả năng), workability (khả năng làm việc), viability (tính khả thi) và believability (số lượng khả tin)

Ngày nay có rất nhiều nghiên cứu, và ứng dụng đã sử dụng ngôn ngữ mô hình i* trong kỹ thuật lấy yêu cầu ở giai đoạn đầu, thiết kế quy trình hay yêu cầu hệ thống Ngôn

Trang 18 ngữ mô hình i* có hai dạng mô hình chính là Strategic Dependency model (SD) và Strategic Rationale model (SR)

 Strategic Dependency model (mô hình chiến lược phụ thuộc) là tập hợp các nút và liên kết, mỗi nút biểu diễn 1 tác nhân và mỗi liên kết giữa 2 tác nhân cho biết tác nhân nào phụ thuộc vào tác nhân khác Mô hình SD được sử dụng để thể hiện các mạng có mục đích, mối quan hệ chiến lược giữa các tác nhân

 Strategic Reationale model (mô hình chiến lược quan hệ) là đồ thị, với nhiều nút và liên kết cùng nhau thể hiện cấu trúc với quan hệ bên dưới Các tác nhân trong mô hình SD sẽ được mở ra (opened up) để cho thấy những ý định cụ thể của nó Mô hình SR cũng có 4 loại nút như mô hình SD là: goal, task, resource, and softgoal và có 3 loại liên kết trong nội bộ của actor là: means-ends links, task decomposition links and contribution links

Có nhiều công cụ để thiết kế và trừu tượng hóa mô hình i* như: openOME, J- PRIM , Tagoon+ Tool, … hay Visio của Mircosoft Mỗi công cụ có 1 cách lưu trữ mô hình khác nhau, như bằng XML của openOME, J-PRIM thì dùng Java lưu trữ bằng MySQL Trước sự đa dạng về các công cụ, mỗi công cụ lại có 1 chuẩn lưu trữ mô hình i* như thế thì i* có 1 chuẩn chung để trao đổi (model interchange format), gọi là iStarML [5] là định dạng mô hình i* bằng XML

Hình 3.2 và Hình 3.3 bên dưới thể hiện hai dạng chính của mô hình i* Mô hình

SD thể hiện mối quan hệ phụ thuộc của các tác nhân với nhau, ví dụ như tác nhân “PhD Student” cũng là (is-a) tác nhân “Student” Với mô hình dạng SR, tác nhân “Student” được mở ra để cho thấy các goal “Travel organized” và mối liên hệ giữa các subgoal, task, resource để có thể đạt được goal này

Hình 3.2: Mô hình SD (Travel Reimbursement)

Hình 3.3: Mô hình SR (Travel Reimbursement) với tác nhân Student được

Biểu diễn mô hình i* dưới dạng XML ( chuẩn của iStarML)

Hình 3.4: Thể hiện mô hình i* dưới chuẩn iStarML với tác nhân Customer as Buyer [Service] cùng các goal, softgoal bên trong