đặt vấn đề bài toán ở phần I.1, trong phân tích thiết kế hướng đối tượng, ta sẽ sử dụng mô hình usecase trong quá trình thiết kế. Tuy nhiên, mô hình usecase chỉ dừng lại ở quá trình phân tích các quy trình nghiệp vụ và phân tích các thực thể. Nếu có quá nhiều ràng buộc hoặc nhiều hoàn cảnh khác nhau, thì làm cách nào để miêu tả những usecase đó? Làm cách nào để biết usecase được nhắc đến trong hoàn cảnh, tình huống nào? Nếu usecase có quá nhiều những luật về nghiệp vụ liên quan, và những luật đó phụ thuốc vào nhiều hoàn cảnh, thì làm cách nào để mô tả hết và đầy đủ? Và thông thường, để phân tích usecase, ta hay vẽ ra các tình huống riêng bằng sequence diagram, hay activity diagram cho các trường hợp này. Dù vậy, khi tình huống tăng lên quá nhiều, đồng thời còn có thể phát sinh thêm tình huống mới trong quá trình vận hành thì việc phân tích có thể trở nên không đủ.
Do đó, từ những câu hỏi và vấn đề trên, thay vào việc mô tả từng tình huống nhất định trong usecase, ta sẽ mô tả đặc điểm chung của các tình huống bằng hoàn cảnh, chủ yếu là sẽ mô tả điều kiện để hoàn thành các tình huống. Vì thế, với những tình huống và usecase thay đổi liên tục, để có thể mô tả một cách chính xác hơn, ta phát sinh thêm khái niệm Policy và Situation, trong đó Policy sẽ tương ứng với khái niệm điều kiện và Situation sẽ tương ứng với khái niệm hoàn cảnh cụ thể. Với những khái niệm phát sinh ấy, nhóm chọn mô hình Hệ thống nghiệp vụ được giới thiệu trong sách Hệ thống nghiệp vụ Modeling with UML, để mô tả cho một bài toán nghiệp vụ bất kỳ nhằm phát triển việc phân tích theo hướng tác tử. Page 21 Báo cáo Luận án tốt nghiệp Xây dựng ngôn ngữ theo hướng tác tử Mục đích chính của mô hình Hệ thống nghiệp vụ là mô tả những giá trị được chia sẻ giữa khách hàng, nhà cung cấp, nhân viên… và định nghĩa vì sao lại tồn tại các mối quan hệ đó.
Mô hình còn đưa ra định nghĩa về việc công việc được hoàn thành như thế nào. Hình 2: Mô hình Hệ thống nghiệp vụ Với mô hình Hệ thống nghiệp vụ, trong phân tích thiết kế hướng đối tượng chỉ áp dụng được một phần của mô hình, chủ yếu là các khái niệm Object, Process, Step, Value, mà không quan tâm đến các giá trị về Situation và Policy. Phần dưới của mô hình Hệ thống nghiệp vụ tương ứng với quy trình của mô hình usecase trong phân tích thiết kế hướng đối tượng. Object Process Value Step Hình 3: Một phần của mô hình Hệ thống nghiệp vụ Như ta đã thấy, lập trình hướng đối tượng chỉ đáp ứng một phần của mô hình Hệ thống nghiệp vụ, nhưng với lập trình hướng tác tử, thì chúng ta có thể áp dụng triệt để.
Nếu áp dụng vào lập trình hướng tác tử, chúng ta sẽ áp dụng được khái niệm Situation và Policy để hoàn thiện hơn cho quá trình phân tích. Page 22 Báo cáo Luận án tốt nghiệp Xây dựng ngôn ngữ theo hướng tác tử 6. Giới thiệu về công cụ Coco/R [1] Trong quá trình thực hiện luận án, nhóm lựa chọn công cụ Coco/R trong việc hỗ trợ việc xây dựng ngôn ngữ. Coco/R là một công cụ sinh ra trình biên dịch, và sẽ sinh ra hai tập tin tên là Parser và Scanner.
Công việc chính của scanner là chia nhỏ các đoạn mã thành các token để parser có thể sử dụng. Scanner định nghĩa token nào sẽ được gửi cho parser, và đưa những gì không được định nghĩa trong cú pháp ngôn ngữ ra ngoài. Parser được xem như trái tim của trình biên dịch. Parser có các công việc như đảm bảo rằng mã nguồn chương trình phù hợp với cú pháp của ngôn ngữ, và sẽ thông báo lỗi khi không phù hợp.
Coco/R có các phiên bản hỗ trợ cho nhiều ngôn ngữ, như C#, Java, C++, Delphi, Modula-2, Oberon và những ngôn ngữ khác. Đề án của nhóm sẽ sử dụng phiên bản Coco/R dùng cho C#. Người dùng phải đưa ra một lớp chính, lớp chính này sẽ gọi tập tin Parser, cũng như gọi các lớp ngữ nghĩa (ví dụ như phần sinh ra code).NET Trên cơ sở của những khái niệm về modal logic và đặt nhãn đã được nhắc đến trong phần II.3, khi thực hiện luận án, nhóm chọn sử dụng .NET mà không phải một ngôn ngữ khác như Java. Nhóm chọn công cụ là .NET là do .NET có hỗ trợ Custom Attribute.
Bản chất của Custom Attribute là một dạng như đánh dấu, hỗ trợ metadata, trong khi Java không hỗ trợ những điều đó. Vì vậy sẽ tốt hơn khi chọn .NET để chuyển nền tảng đặt nhãn vào thực tế. Custom attribute [5] Là những thuộc tính được tạo ra vì mục đích riêng của người sử dụng. Thuộc tính là những public class.
Mỗi thuộc tính phải có ít nhất một constructor. Các constructor có thể được overload để cho phép thuộc tính được ứng dụng vào các class bằng nhiều cách. Để tạo một custom attribute, ta phải bắt nguồn từ new custom attribute class từ class System. Phạm vi và mục tiêu của thuộc tính có thể được định nghĩa bằng cách áp ụng AttributeUsage.
Sử dụng Custom Attribute [8] Việc tạo ra Custom Attribute là một tiến trình đơn giản. Các bước được tiến hành như sau: Tạo ra Custom Attribute bởi một lớp bắt nguồn từ System.Attribute Page 23 Báo cáo Luận án tốt nghiệp Xây dựng ngôn ngữ theo hướng tác tử Nếu cần, xác định các properties gắn liền với một thuộc tính. Một số thuộc tính như các thuộc tính Serializable không có property. Định nghĩa một constructor cho thuộc tính có chứa các đối số cần thiết (nếu có) để xây dựng các thuộc tính.
Tùy chọn, xác định phạm vi của Custom Attribute bằng cách xác định các thuộc tính AttributeUsage Metadata (Siêu dữ liệu) Metadata là thông tin về dữ liệu nghĩa là thông tin về kiểu, code, assembly,… mà được lưu trữ cùng với chương trình. Attibutes là một cơ chế để thêm metadata, chẳng hạn như hướng dẫn trình biên dịch và các dữ liệu khác về dữ liệu, phương thức, và các class tới chương trình riêng của mình. Thuộc tính được đưa vào metadata và có thể nhìn thấy qua ILDasm và các công cụ metadata khác. Reflection là quá trình mà theo đó một chương trình có thể đọc dữ liệu riêng của mình.
Một chương trình được cho là để phản ánh về chính nó phải giải nén metadata từ assembly và sử dụng metadata hoặc thông báo cho người dùng hoặc để sửa đổi hành vi của chính mình. Hướng giải quyết bài toán Sau khi tìm hiểu được những khái niệm được đặt ra trong bài toán thứ nhất, ta sẽ áp dụng những khái niệm đó lần lượt vào hai bài toán tiếp theo, bài toán về hướng phân tích và bài toán xây dựng ngôn ngữ. Hướng tiếp cận bài toán phân tích Chúng ta có thể thấy rằng, ngày nay, với các phần mềm ngày càng phát triển, hệ thống của chúng sẽ trở nên phức tạp hơn. Khả năng nắm bắt và kiểm soát sự phức tạp đó đi kèm với khả năng trình bày hệ thống một cách toàn diện.
Xuất phát từ những bài toán thực tế, các phương pháp phân tích đã ra đời. Như đã trình bày, phân tích theo hướng tác tử có thể giải quyết những vấn đề mà phân tích theo hướng đối tượng chưa làm được. Và quá trình phân tích của hai hướng tác tử và đối tượng rõ ràng là có sự khác biệt. Như đã chỉ ra trong mô hình Hệ thống nghiệp vụ, phân tích hướng đối tượng trước hết sẽ đi từ mô tả giả định đến usecase.
Tuy nhiên, một usecase thường có rất nhiều những luật nghiệp vụ liên quan, mà những luật đó lại phụ thuộc vào hoàn cảnh. Để phân tích bằng usecase, ta hay vẽ ra các tình huống riêng bằng sequence diagrams, hay activity diagrams cho các trường hợp này. Dù vậy, khi các tình huống tăng lên quá nhiều, đồng thời tình huống còn có thể phát sinh thêm trong quá trình vận hành thì việc phân tích có thể trở nên không đủ. Do đó, thay vào việc mô tả từng tình huống nhất định trong usecase, ta sẽ mô tả đặc điểm Page 24 Báo cáo Luận án tốt nghiệp Xây dựng ngôn ngữ theo hướng tác tử chung của các tình huống bằng hoàn cảnh, chủ yếu ở đây là điều kiện để hoàn thành các tình huống.
Tương tự như trong phân tích hướng đối tượng, khi đi theo phân tích hướng tác tử, chúng ta cũng bắt đầu từ mô tả giả định. Dựa vào mô tả giả định đó, chúng ta sẽ xác định các thành phần của bài toán, như Agent, Condition, Context, Role… 1. Context Khái niệm Context Như chúng ta đã biết, để có thể xem xét chính xác một vấn đề, ta cần đặt nó vào một hoàn cảnh cụ thể (posible word), vì khi hoàn cảnh thay đổi, thì những tương tác của tác nhân với môi trường ngoài xung quanh cũng sẽ thay đổi theo. Các hoàn cảnh cụ thể thường được xác định bởi một tập hợp các điều kiện.
Với khái niệm về possible word hay hoàn cảnh cụ thể ấy, khi áp dụng vào việc mô tả lý thuyết vào bài toán, chúng ta có khái niệm tương ứng là Context. Xác định Context Ta xác định context từ bản mô tả trong lập trình hướng tác tử, bằng cách dựa vào các dòng thông tin lưu hành trong quá trình tương tác giữa tác nhân với hệ thống, ta xác định được những context tồn tại. Condition Khái niệm Condition Từ khái niệm gán nhãn trong modal logic, ta nhận thấy việc context được gán nhãn sẽ tương ứng với Condition do người dùng định nghĩa. Khái niệm Condtion cũng tương ứng với khái niệm về Policy trong mô hình Hệ thống nghiệp vụ.
Xác định Condition Từ những quy tắc, ràng buộc trong hệ thống, ta chú ý đến với những quy tắc ấy, ta sẽ có những điều kiện cụ thể tương ứng nào. Condition là tập hợp các điều kiện quy định với điều kiện này thì method sẽ thực thi như thế nào. Role Khái niệm Role Ta thấy Context sẽ sinh ra usecase, trong usecase có khái niệm về Actor và các mối tương tác giữa Actor. Mặt khác, context lại mô tả tình huống chung của tất cả các Page 25 Báo cáo Luận án tốt nghiệp Xây dựng ngôn ngữ theo hướng tác tử usecase mà actor đóng vai trò một role, từ đó chúng ta sẽ nảy sinh ra khái niệm về Role.
Xác định Role Bản chất của role cũng là một tập hợp các capability, và role cũng được gán nhãn trong một hoàn cảnh cụ thể. Vì vậy, vấn đề đặt ra là làm sao phân biệt được role và agent trong bài toán. Để xác định role, ta thường trả lời các câu hỏi sau: Ai là người có tương tác với hệ thống?