PHẦN II CÁC KẾT QUẢ ĐẠT ĐƯỢC Chương III Thiết kế hệ thống.
3.2 Kiến trúc của hệ thống thể hiện trực quan WiSSim Visualizer
Để xây dựng một hệ thống có khả năng thể hiện trực quan tốt, người dùng có thể tương tác dễ dàng thì hệ thống phải đảm bảo những yêu cầu sau:
- Hệ thống phải hoạt động đúng. Sự hoạt động của các phần tử trong mạng phải
đảm bảo diễn ra theo đúng quy định dữ liệu trong trace file. Việc đánh giá tính đúng đắn ở đây bao gồm 2 yếu tố: thông tin hoạt động của các phần tử trong mạng (sự kiện gửi/nhận gói tin…) và thông tin thời gian sự kiện đó xảy ra.
- Hê thống phải đảm bảo về bộ nhớ và thời gian xử lý. Hệ thống sử dụng bộ nhớ
một cách tiết kiệm nhất, tránh các dữ liệu dư thừa. Bởi số lượng các sự kiện là rất lớn (tới hàng chục triệu sự kiện) nên chỉ cần 1 chút thông tin dư thừa sẽ có khả năng bị nhân lên hàng chục triệu lần. Tracefile đầu vào có dung lượng khá lớn (từ vài chục tới vài trăm Mb với dữ liệu là văn bản thuần túy) nên việc đọc thông tin mất khá nhiều thời gian. Chúng tôi đã thử nghiệm và lựa chọn một số phương án tối ưu cho quá trình đọc dữ liệu đầu vào này. Thời gian hiện tại là hoàn toàn có thể chấp nhận được.
- Hệ thống phải đảm bảo dễ sử dụng, không mất nhiều thời gian để học. Những
chức năng được chúng tôi thiết kế không ở quá sâu. Chỉ cần một vài thao tác là có thể thực hiện được. Chúng tôi cố gắng sử dụng những hình ảnh mang tính gợi nhớ và các phím tắt để người dùng sử dụng dễ dàng và nhanh chóng.
Từ những yêu cầu cơ bản ở trên, chúng tôi đề xuất ra hệ thống dưới tên gọi “WiSSim Visualizer” có khả năng tái thể hiện trực quan quá trình hoạt động mạng với đầu vào là trace file.
Trong phạm vi đồ án, chúng tôi tập trung đề cập đến vấn đề xây dựng nền tảng
Engine phục vụ cho hệ thống WiSSim Visualizer.
Về ý tưởng cơ bản, chúng tôi thiết kế theo cơ chế MVC (Model-Control-View). Vì vậy, WiSSim Visualizer bao gồm 4 phần cơ bản:
- WiObject: Cung cấp các đối tượng cơ bản thông qua các lớp (class) và giao diện (interface). Các lớp cơ bản này đóng vai trò quan trọng trong việc xây dựng hệ thống. Đây chính là những đơn vị nhỏ nhất, những viên gạch đặt nền móng cho việc tái thể hiện mô phỏng mạng.
- WiModel: thực hiện việc phân tích trace file thành các đối tượng, cung cấp dữ liệu cho việc mô phỏng mạng. Những dữ liệu này bao gồm thông tin về toàn bộ mạng, thông tin về các node có trong mạng và thông tin các gói tin được vận chuyển trong mạng. Đó là những thông tin thể hiện tĩnh (mạng ở trạng thái tĩnh, chưa hoạt động). Ngoài ra, thông tin về các sự kiện cũng được lưu trữ (những thông tin này thể hiện sự hoạt động của mạng, sự liên kết giữa các phần tử trong mạng với nhau). Người đọc sẽ hiểu chi tiết hơn ở phần sau.
- WiEngine: điều khiển sự hoạt động của quá trình mô phỏng. Mọi thao thao tác liên quan tới dữ liệu để thể hiện đều được WiEngine thực hiện. WiEngine có vai trò lập lịch các sự kiện. Từ dữ liệu đã được tổ chức, WiEngine sắp xếp các sự kiện đó, khởi tạo một cơ chế gọi sự kiện theo thời gian thực. Các sự kiện biểu diễn quá trình hoạt động của các node trong mạng. WiEngine đảm bảo tính hoạt động đúng đắn, chính xác của việc tái mô phỏng sự hoạt động trong mạng. Ở trong này, chúng tôi cài đặt một số cơ chế phức tạp mà chúng tôi sẽ trình bày ở ngay dưới đây.
- WiView: bao gồm 2 thành phần: phần thông tin văn bản (console) và phần đồ họa (graphic). Đây là phần giao diện thể hiện trực quan và cho phép người dùng tương tác. Đây là phần người dùng trực tiếp tương tác, người dùng có thể nhìn thấy toàn bộ trạng thái mạng, thông tin của các gói tin, các node trong mạng. Đồng thời, người dùng có thể lựa chọn một số thông tin quan tâm để lọc các sự kiện liên quan tới các vấn đề đang được quan tâm đó. Trong phạm vi đồ án, chúng tôi
không trình bày chi tiết phần này. Người đọc có thể tham khảo đồ án “Module xử
lý đồ họa trong hệ Wissim – Hệ thống mô phỏng mạng cảm biến không dây”
của bạn Nguyễn Quốc Hoàng, Sinh viên K53, lớp Công nghệ phần mềm. Sự quan hệ giữa các thành phần trong hệ thống:
Hình Kiến trúc cơ bản của WiSSim Visualizer
Trong sơ đồ kiến trúc hệ thống ở trên, chúng tôi thiết kế những thành phần có thể hoạt động theo từng pha độc lập mà không ảnh hưởng nhiều tới các thành phần khác.
Trong quá trình thiết kế, chúng tôi đã rất chú ý vấn đề độc lập giữa các thành phần bởi 3 yếu tố sau:
- Việc thiết kế các thành phần là độc lập giúp cho việc module hóa tốt hơn, đảm
bảo dễ cài đặt, dễ bảo trì.
- Khi chia ra nhiều thành phần nhỏ, chúng tôi dễ phân chia công việc. Nhiệm vụ
của mỗi người không quá phụ thuộc vào người còn lại bởi chỉ quan tâm dữ liệu đầu vào và ra của mỗi pha.
- Việc thiết kế như vậy sẽ đánh giá tốt hơn cho kiểm tra tiến độ phát triển phần
mềm. Chúng tôi có thể đánh giá kết quả đạt được sau mỗi giai đoạn phát triển. Từ đó chúng tôi có thể xác định khâu nào nên được tập trung nhiều hơn, đảm bảo tiến độ dự án.
Phần kiến trúc WiBase có liên quan tới toàn bộ các thành phần khác. WiBase cung cấp các lớp cơ bản để xây dựng ứng dụng. Trong WiBase, một số lớp (class) được chúng tôi xây dựng lại từ nền tảng NS2 bao gồm Wiobject/ Node/ Packet/ Event/ Network … Những lớp này tương ứng với các lớp trong NS2 và có ý nghĩa tương đương. Từ đó, việc đọc dữ liệu từ trace file (do NS2 sinh ra) luôn đảm bảo tính tương thích, người dùng NS2 đã rất quen với những khái niệm này.
Ngoài ra, những lớp khác được chúng tôi xây dựng để phục vụ cho hệ thống. Mỗi lớp đều có tác dụng cụ thể, bảng dưới là những lớp cơ bản của hệ thống:
STT Lớp trong gói wiBase Nhiệm vụ
1 WiObject Tương ứng với NsObject trong NS2. Thành phần dữ
liệu cơ bản để wiModel sử dụng để phân tích dữ liệu
2 WiScheduler Phục vụ cho việc lập lịch các sự kiện. Thành phân cốt
lõi của Engine để thiết lập mô phỏng.
3 WiException Lớp ngoại lệ cơ bản. Khi có bất cứ ngoại lệ nào nảy
sinh trong quá trình mô phỏng, một ngoại lệ thuộc ngoại lệ này sẽ được nảy sinh.
4 WiListener Chúng tôi sử dụng cơ chế CallBack trong java bằng
cách sử dụng các giao diện (interface). Việc này đảm bảo tốt cơ chế module hóa các thành phần.
Bảng Bảng các gói cơ bản trong hệ WiSSim Visualizor
Để thực hiện tốt ý tưởng của mình, chúng tôi đã sử dụng cơ chế “lắng nghe sự kiện” nhằm độc lập các thành phần hoạt động trong hệ thống. Mỗi sự kiện được gắn kết với một giao diện tương ứng, đại diện cho loại hành động có thể thực hiện. Với mỗi thành phần đều có giao diện tương ứng riêng:
STT Giao diện baseInterface Ý nghĩa
1 IfilterDataCollector Do chúng tôi phân tích trace file theo phương
thức SAX (Simple API for XML) nên chúng tôi đã viết lại các phương thức của thư viện. Việc này sẽ thuận tiện hơn cho việc phân tích trace file đầu vào rất nhiều.
2 OnParseListener Bao gồm các lắng nghe cho việc phân tích trace
file
2 OnAdapterListener Đóng vai trò cầu nối giữa Engine và Model. Giao
diện này cho phép Engine lấy thông tin thu được từ việc phân tích trace file, điều khiển quá trình phân tích.
thức để điều khiển.
4 OnEventSchedulerListene
r
Liên quan tới lớp Event. Mỗi sự kiện đều có hành động này nếu chúng được thể hiện (cơ chế lọc, filter)
5 OnOutputStreamListener Mỗi đối tượng mạng (đối tượng của lớp
WiObject) đều có chức năng này. Đây là dữ liệu đầu ra của việc lập lịch (schedule)
6 OnEngineControlListener Bao gồm các phương thức cho phép một đối
tượng của WiView có thể lắng nghe hoặc điều khiển WiEngine
Bảng Các giao diện trong hệ WiSSim Visualizor
Mỗi thành phần sẽ cài đặt những giao diện mà thành phần đó cần được cung cấp. Chẳng hạn, WiEngine sẽ chứa một giao diện của WiAdapter ( đó là OnAdapter -Listener). Khi đó, WiEngine không biết phía WiModel làm những công việc gì, mà chỉ cần quan tâm WiModel có thể cung cấp các chức năng và giao diện đó là đủ.
Một ví dụ khác, WiView bao gồm hai thành phần: thể hiện qua giao diện văn bản (WiConsole) và giao diện đồ họa (WiGraph), mỗi thành phần hoạt động hoàn toàn độc lập với nhau, nhưng đều cùng được cài đặt giao diện OnEngineControlListener, từ đó, cả hai đều có thể lắng nghe chung 1 WiEngine duy nhất. Khi có bất kỳ sự kiện này xảy ra ở phía WiEngine, cả WiConsole và WiGraph đều có thể biết và thực hiện hành động tương ứng.
Hình Cơ chế lắng nghe sự kiện trong hệ thống WiSSim Visualizer
3.1.1 WiModel
WiModel đóng vai trò quản lý dữ liệu cho toàn bộ hệ thống WiSSim Visualizer. Thông tin về mạng từ trace file cung cấp sẽ được thành phần WiModel phân tách và tạo dựng lại thành các đối tượng mạng tương ứng. Những đối tượng mạng ở đây có thể là node, packet, hay các event (sự kiện hoạt động của các phần tử node/packet). Những dữ liệu này sẽ được thành phần WiEngine sử dụng cho quá trình lập lịch, kiểm soát quá trình hoạt động của mạng.
Đặc điểm của thành phần WiModel là phải xử lý dữ liệu với dung lượng lớn. Những tệp tin xử lý có kích thước từ vài Mb tới vài trăm Mb văn bản. Khi đó thời gian phân tích trace file trở thành một vấn đề cần phải giải quyết.
Hình Cơ chế hoạt động của WiModel
Đầu vào là trace file dưới định dạng ngôn ngữ XML. Đầu ra sẽ là danh sách các sự kiện và đối tượng trong mạng.
Như đã nói ở phần định dạng của trace file, chúng tôi sử dụng thư viện SAX để
phân tích. Chúng tôi mở rộng các lớp mặc định của thư viện SAX để hoạt động phù hợp với mục đích của chúng tôi hơn. Thông qua hai lớp cơ bản: SAX Event Handler và SAX Error Handler. Phần xử lý thông tin được điều khiển chính trong lớp WiModelProtocol. Lớp này đóng vai trò xử lý với từng loại dữ liệu đầu vào sẽ tạo ra các đối tượng cụ thể. Các đối tượng ở đây được tạo ra từ những lớp cơ bản ở trong thành phần WiBase (đối tượng của các Node/Packet/Event…) . Sau quá trình phân tích từng loại dữ liệu, những dữ liệu đó sẽ được lưu ở trong một đối tượng của lớp WiModelManager. Các thành phần khác trong hệ thống có thể truy cập dữ liệu đó thông qua một giao diện mà chúng tôi gọi là WiAdapter. WiAdapter bao gồm những phương thức cho phép lấy một cách nhanh chóng các thông tin về mạng.
Chúng tôi đã thử nghiệm cài đặt việc phân tích trace file ở cả hai ngôn ngữ lập trình: JNI và Java. Kết quả thu được hoàn toàn rất khả quan cho hướng đi mà chúng tôi đã xác định.
Hình Biểu đồ phân tích trace file bằng Java và JNI
Kết quả cho thấy việc sử dụng Java cho kết quả nhanh hơn hẳn JNI (lý do mà chúng tôi nhận thấy đó là vì Máy ảo java phải mất thêm một thời gian để tải thư viện .dll vào bộ nhớ). Hơn nữa là thời gian phân tích tracefile cũng rất ngắn (32Mb với 3 giây) là hoàn toàn có thể chấp nhận được.
Thời gian xử
Bảng so sánh các lớp thư viện SAX mặc định và mở rộng của WiModel
Thư viện SAX WiModel Tác dụng
startDocument() startDocument() Bắt đầu phân tích
endDocument() endDocument() Kết thúc phân tích
startElement() startElement() Bắt đầu 1 thẻ Tag
endElement() endElement() Kết thúc 1 thẻ Tag
characters() character() Đọc nội dung trong 1 thẻ
parseAttributes() Đọc các thuộc tính của thẻ
Bảng Bảng so sánh thư viện SAX và WiModel
Khi thêm phương thức parseAttributes chúng tôi đã dễ dàng hơn trong việc phân tích tracefile rất nhiều.
Sau quá trình phân tích file trace, chúng tôi thực hiện thêm một bước phân tích để tạo dữ liệu cần thiết cho quá trình mô phỏng sau này. Sau quá trình phân tích dữ liệu, hệ thống có thể dễ dàng lấy dữ liệu với tốc độ nhanh hơn và bổ sung các dữ liệu cần thiết cho quá trình mô phỏng.
3.1.2 WiEngine
WiEngine đóng vai trò cốt lõi trong hệ thống WiSSim Visualizer. Thành phần này có nhiệm vụ lập lịch các sự kiện, điều phối hoạt động của quá trình mô phỏng các phần tử trong mạng. WiEngine cung cấp các chức năng để các thành phần khác có thể diều khiển (chẳng hạn như dừng/ tiếp tục mô phỏng, điều khiển phân tích trace file nào…) Cơ chế hoạt động của WiEngine thể hiện sơ lược qua sơ đồ:
Hình Cơ chế hoạt động của WiEngine
WiEngine giữ một tham chiếu tới WiAdapter của thành phần WiModel. Như đã nói ở phần giới thiệu WiModel, Adapter này cung cấp những hàm cho phép Engine lấy thông tin từ Model. Từ đó những dữ liệu này sẽ phục vụ cho quá trình tái mô phỏng mạng. Với cơ chế lập lịch thông qua lớp ScheduledThreadPoolExecutor, các sự kiện được lập lịch một cách song song (qua cơ chế Pool). Cơ chế này cho phép người dùng quản lý số tác vụ (Thread) hoạt động đồng thời tại một thời điểm. (Ở đây, chúng tôi đã coi như các thread có khả năng hoạt động xử lý song song với nhau). Từ một đối tượng lập lịch này, chúng tôi bổ sung thêm cơ chế lọc (filter), cho phép người dùng chỉ xem một số thông tin mà họ quan tâm. Từ đó, người dùng có thể tập trung hơn trong quá trình đánh giá kết quả, phân tích sự hoạt động của mạng chính xác, nhanh chóng hơn.
Trong phần này chúng tôi có ba vấn đề muốn đề cập tới. Thứ nhất đó là cơ chế lập lịch của chúng tôi. Thứ hai là cơ chế phát sinh sự kiện, khi có một sự kiện trong mạng, WiEngine sẽ xử lý như thế nào và thứ ba là cơ chế lọc các sự kiện để tránh việc quá nhiều thông tin được biểu diễn.
a. Cơ chế lập lịch sự kiện
Lớp WiEngine kế thừa từ lớp WiScheduler. Ở trong WiScheduler chứa một lớp thực hiện việc lập lịch cho các sự kiện: WiSchedulerThreadPoolExecutor. Lớp này kế thừa từ ScheduledThreadPoolExecutor.
Lớp ScheduledThreadPoolExecutor hoạt động theo cơ chế đẩy các sự kiện vào một hàng đợi. Mỗi hàng đợi do 1 Thread quản lý. Cơ chế này giúp cho việc lập lịch có thể hoạt động đồng thời nhiều sự kiện (cùng một thời gian) và hoạt động độc lập, rất phù hợp với mục đích của chúng tôi.
Hình Cơ chế hoạt động của lớp ScheduledThreadPoolExecutor
Ngoài ra, lớp WiSchedulerThreadPoolExecutor cũng mở rộng hơn bởi chúng tôi đã thêm các chức năng: tạm dừng/tiếp tục mô phỏng, thông qua các phương thức: pause() resume(). Từ đó, WiEngine sẽ tập trung xử lý đúng nhiệm vụ mà không cần quan tâm tới việc dừng hay tiếp tục mô phỏng.
Để quá trình mô phỏng diễn ra mượt hơn, chúng tôi đã lấp đầy các khoảng trống rời rạc sự kiện bằng các sự kiện ảo với thời gian khoảng cách đủ nhỏ để không xảy ra hiện tượng giật hình khi mô phỏng.
b. Cơ chế phát sinh sự kiện
Những sự kiện (Event) được lập lịch bởi đối tượng của lớp WiScheduler Thread- PoolExecutor sẽ được gọi qua phương thức write(WiObject data); của giao diện OnEvent- SchedulerListener. Chúng tôi đã tạo ra lớp EventTraceListener để thực hiện việc này.
Mỗi đối tượng WiObject đều được cài đặt một đối tượng OnOutputStream- Listener. Đối tượng này sẽ có nhiệm vụ gửi chính Sự kiện hoặc thông tin sự kiện (bao gồm Node/ Packet) cho phía WiView xử lý. Dưới đây là sơ đồ chi tiết:
Hình Cơ chế gọi sự kiện
c. Cơ chế lọc sự kiện
Chúng tôi gọi cơ chế lọc này là Filter. Khi WiView chỉ muốn thể hiện một số loại sự kiện mà không phải tất cả, khi đó, WiView phải đăng ký những loại sự kiện đó với WiEngine. Bởi vì tất cả các đối tượng cơ bản (Node/Packet/Event…) đều được kế thừa từ WiObject. Ở trong WiObject chúng tôi đã cài đặt giao diện OnOutputStream –Listener