Luận văn Tìm hiểu về tiếp cận theme và ứng dụng của cách tiếp cận vào xây dựng hệ thống điện thoại

hóm hành vi tương ứng các template đó. Trong một nhóm hành vi đơn , có thể có một số các operation template và attribute trong cùng class template. Để thuận tiện, ta mô tả chúng với một kí tự danh sách { }. Cho ví dụ, nhóm template sau có 6 operation template, trong ClassA có ba operation template, và trong ClassB có ba operation template. Nhớ rằng hoạt động đầu tiên trong nhóm template là hoạt động kích hoạt hành vi crosscutting trong biểu đồ tuần tự tương ứng, trong trường hợp này là ClassA.op1(). Và có tempalte class cho mô tả operation template và attribute, như trong ví dụ này hai class template là ClassA, ClassB, giúp không có sự xung đột giữa ClassA.op1() và ClassB.op1(). 3.2.2.5 Tham chiếu Template structure và hành vi Khi thiết kế crosscutting có ít nhất một số mô hình hành vi trong nó sẽ được kích hoạt bởi hành vi bên ngoài theme. Trong các theme base đó, các operation mà kích hoạt một chuỗi hành vi crosscutting xuất hiện trong các class khác nhau, chúng sẽ được nhóm trong một class template đơn để bắt hành vi crosscutting. Có thể có nhiều class mà được tổng hợp với class template bởi vì các class đó có các hoạt động mà kích hoạt các crosscutting hành vi liên quan (miêu tả trong chương sau). Điều này gợi ý cho việc sử dụng class template giống như kiểu tham chiếu trong thiết kế theme aspect. Giả sử, chúng ta có một class gọi là ClassA trong thiết kế aspect mà không phải là một class template, nó không có hành vi cắt ngang nào được kích 35 hoạt bên ngoài aspect. Tuy nhiên, chúng ta mong muốn ClassA được thêm vào thiết kế tổng thế. Cũng giả sử rằng, ClassA có một attribute gọi là att1. Nếu kiểu của att1 là template, có nhiều khả năng nó sẽ có trong tổng thể thiết kế? Nó là nhập nhằng bởi vì có nhiều class được tổng hợp với class template. Để tránh rối loạn Theme/UML không cho phép mở rộng tham chiếu đến class template.Tương tự, ta xét việc gọi các phương thức trong một class template từ một class khác trong theme aspect. Nếu một method trong ClassA (không phải template) gọi một method trong một class template, method đó có nên được thực thi khi mà theme aspect được tổng hợp với các theme base ? Điều đó lại là nhập nhằng, và để tránh rối loạn, Theme/UML không cho phép mở rộng gọi method trong một class template. Hình 3-7 ClassB là một class template, ClassA và ClassC thì không phải là template. ClassA không được tham chiếu đến thuộc tính att1- kiểu template trong ClassB, phương thức op3() trong ClassC không được tham chiếu đến op2() trong ClassB. Hình 3-7 Tham chiếu cấu trúc và hành vi template 36 Chương 4 Tổng hợp theme Chúng ta thiết kế mỗi theme individually mà không bao gồm các tham chiếu trực tiếp đến các theme khác. Bởi vì chúng ta muốn tránh đặc điểm rải rác và lẫn rối giữa các theme, ảnh hưởng xấu đến việc mô-đun hóa và gây nên sự hỗn độn cho sự khoa học của phần mềm. Trong chương này, chúng ta sẽ xem xét, xác định làm thế nào mà các theme liên quan đến nhau và làm thế nào chúng được tổng hợp thành một ứng dụng mạch lạc duy nhất. Với cách tiếp cận Theme’s symmetric, mỗi theme là một concern trong miền. Cần phải tổng hợp các theme cần thiết trong ứng dụng để đưa ra một ứng dụng mạch lạc. Tập các theme để tổng hợp cho ứng dụng có thể bao gồm tất cả các theme đã được thiết kế, hoặc các ứng dụng khác nhau có thể chỉ yêu cầu những tập con khác nhau từ những theme đã thiết kế. Thông thường, các bước trong quá trình tổng hợp là : 1 Chọn các theme để tổng hợp. Sự tổng hợp trong Theme/UML ở mức phần tử theme. 2 Xác định các phần tử thiết kế trong các theme tương đương nhau. Các theme mà có đặc tả cho cùng khái niệm miền sẽ được so khớp. 3 Chỉ ra làm thế nào các theme được tích hợp. Theme/UML cung cấp hai loại tích hợp : merge (hợp nhất) và override (ghi đè). 4 Chỉ ra làm cách giải quyết xung đột giữa các phần tử thiết kế được so khớp. 5 Xác định các hành vi kích hoạt trong theme base để bind (kết dính) tới template trong một theme aspect. 4.1 Pick Theme Đầu tiên bạn cần chọn các theme để tổng hợp cho ứng dụng và vẽ relationship tổng hợp (mối quan hệ tổng hợp) giữa các theme đã chọn. Một relationship tổng hợp là một kiểu mối quan hệ được xác định với Theme/UML. Kí hiệu cho một relationship tổng hợp là đường cong nét đứt giữa các phần tử thiết kế để tổng hợp. Trong Theme/UML tổng hợp xảy ra tại các mức phần tử theme: class, operation, attribute, và đầu tiên phải chọn các theme để tổng hợp. Các theme mà chứa các phần tử mà có ý nghĩa tương đương nhau, khớp nhau thì sẽ được chọn để tổng hợp theme. Hoặc các theme không có các khái niệm chung, nhưng thuộc một miền trong hệ thống 37 cũng được tổng hợp. Sử dụng các relationship tổng hợp giữa các phần tử thiết kế sẽ được tổng hợp trong bối cảnh của tổng hợp theme. Không giới hạn số theme được tổng hợp đồng thời. Kết quả của mọi tổng hợp được chứa trong một theme mới. Ta có thể đặt tên cho theme mới với nhãn ThemeName[“name”] gắn trên relationship tổng hợp, “name” là tên của theme tổng hợp. 4.2 Xác định các phần tử thiết kế so khớp Khi chúng ta tổng hợp các theme, cơ bản là lấy tất cả các phần tử từ mỗi theme input (các theme được chọn để tổng hợp) và đặt chúng vào cùng một theme mới, vì thế ta muốn đảm bảo các phần tử chia sẻ cùng khái niệm được đặt vào theme mới. Tổng hợp đơn giản nhất là khi các thiết kế các theme không có khái niệm chung. Nhưng chúng miêu tả các khái niệm trong một miền hệ thống. Chúng xuất hiện trong theme kết quả với sự tách biệt nhau, không có relationship tổng hợp giữa chúng. Tuy nhiên,thường thì các theme input cung cấp các thiết kế có các khái niệm chung, từ góc nhìn các requirements của chúng. Trong thiết kế tổng hợp, các khái niệm chung phải được tổng hợp. Có hai cách so khớp các phần tử thiết kế: so khớp tường minh (explicit) và so khớp ngầm định (implicit). Hình 4-1 So khớp các phần tử thiết kế 38 4.2.1 So khớp tường minh Với phương pháp này, vẽ tường minh một relationship tổng hợp giữa các phần tử là khái niệm miền giống nhau. Relationship tổng hợp được xác định giữa các phần tử thiết kế cùng kiểu để chỉ ra các phần tử so khớp và cần được tổng hợp. Hình 4-1 , ở phía bên trái, tổng hợp Theme1 và Theme2 là được xác định với hai relationship tổng hợp. Vẽ một relationship tổng hợp giữa các theme được tổng hợp và một relationship tổng hợp giữa ClassB trong Theme1 và ClassB trong theme2 chỉ ra hai class được so khớp khái niệm, và ClassB xuất hiện một lần trong kết quả thiết kế tổng hợp. Phải dùng phương pháp tiếp cận này , khi các class không có cùng tên nhưng vẫn miêu tả cùng khái niệm, relationship tổng hợp được chỉ ra rõ ràng. 4.2.2 So khớp ngầm định So khớp tường minh các phần tử với một relationship tổng hợp cho mọi so khớp là hữu ích khi các phần tử không có cùng tên. Tuy nhiên, nó có thể nặng nề (và lộn xộn). Ta có thể định nghĩa một nguyên tắc cho relationship tổng hợp chỉ rõ các phần tử được đặt tên tương tự nhau được so khớp. Ở bên phải hình 4-4, chỉ có một relationship tổng hợp giữa các theme được tổng hợp, được gắn thêm nhãn là match[name]. Nhãn này chỉ ra rằng các class trong các theme cùng tên được so khớp và nên được tổng hợp. Ở đây các ClassB trong theme1, và theme2 sẽ được so khớp. Với nhãn match[name], ta có thể nói rằng bất kì phần tử nào nằm trong các phần tử so khớp mà có cùng tên sẽ được xem xét để so khớp: các class có cùng tên nằm trong các theme so khớp sẽ được so khớp; các attribute có cùng tên nằm trong các class so khớp cũng cần được so khớp … Relationship tổng hợp kiểu ngầm định là một relationship tổng hợp bắt buộc, chỉ ra các phần tử đặt tên giống nhau được so khớp như một sự bắt buộc. Ta có thể sử dụng một relationship tổng hợp tường minh giữa các phần tử bạn muốn so khớp mà không được phủ bởi nhãn match[name], nếu hai phần tử đó không cùng tên . Tất nhiên, chúng ta không muốn các phần tử có tên ngẫu nhiên giống nhau được so khớp. Chúng có thể không so khớp một cách tường minh bằng cách thêm một relationship tổng hợp với nhãn dontMatch giữa các phần tử không muốn so khớp. 4.2.3 Các nguyên tắc cho so khớp khái niệm chung với relationship tổng hợp Một đặc điểm quan trọng nhất của một phần tử thiết kế là xem xét cú pháp hợp lệ của một relationship tổng hợp, dù nó là một container chứa các phần tử khác, hoặc nó 39 là một thành phần của một phần tử khác (hoặc đồng thời là cả hai). Ví dụ attribute và operation được chứa trong một class; các class được chứa trong một theme… Quan hệ container/composition giữa các phần tử thiết kế là quan trọng cho xử lý tổng hợp, nó ảnh hưởng đến xác định các phần tử so khớp và xác định namespace của các phần tử được tổng hợp. Sau đây là các nguyên tắc cho so khớp : -Một relationship tổng hợp chỉ có thể vạch ra giữa các phần tử cùng kiểu. -Khi so khớp các phần tử thiết kế, đầu tiên cần vạch ra relationship tổng hợp giữa hai hay nhiều theme chứa các phần tử đó. -Hai (hoặc hơn) các phần tử thiết kế có thể được so khớp (tường minh hay ngầm định) chỉ khi containers của chúng được so khớp. Mọi phần tử tổng hợp phải có một namespace, điều này đảm bảo không có rối loạn trong container chứa các phần tử tổng hợp. -Mỗi phần tử thiết kế chỉ được so khớp trong một tập các phần tử so khớp. Có nghĩa là mọi phần tử thiết kế chỉ được tổng hợp trong một bản thiết kế tổng hợp. Nguyên tắc này nhằm không có sự rối loạn với tham chiếu trong kết quả tổng hợp. - Theme aspect được phép có ngoại lệ với quy luật “match –once”. Hành vi được định nghĩa trong theme crosscutting có thể được tổng hợp với nhiều phần tử khác nhau mà thay thế template sử dụng trong crosscutting hành vi. 4.3 Kiểu tích hợp- Integration Theme/UML xác định hai lối tích hợp để xác định cách lựa chọn các thành phần trong phần tử input đưa vào kết quả tổng hợp. Tích hợp merge (hợp nhất), tích hợp override (ghi đè). 4.3.1 Tích hợp merge Thông thường, kết quả tổng hợp của hợp nhất theme là sự hợp nhất của các mô hình cấu trúc và hành vi trong các theme input. Các mô hình class được hợp nhất vào một class đơn trong kết quả tổng hợp. Khi tổng hợp các mô hình class, các phần tử cấu trúc không được so khớp sẽ được thêm vào mô hình class tổng hợp. Các phần tử cấu trúc được so khớp sẽ xuất hiện chỉ một lần trong thiết kế. Các hoạt động được so khớp sẽ hợp nhất theo nghĩa: sự thi hành của một trong các hoạt động so khớp sẽ kích hoạt sự thi hành của tất cả hoạt động so khớp. Hình 4-2 minh họa kết quả của việc hợp nhất hai theme đơn giản. 40 Hình 4-2. Hợp nhất khái niệm so khớp. Các lớp so khớp (ví dụ hai lớp ClassB trong hai theme) và các attribute so khớp của chúng (a và b) xuất hiện chỉ một lần trong mô hình tổng hợp. Tất cả các elements khác được thêm vào không thay đổi trong mô hình tổng hợp. Khi các phần tử so khớp là container cùng kiểu, tất cả các phần tử thành phần của chúng được hợp nhất vào một container tổng hợp. Trong tích hợp merge, mũi tên relationship tổng hợp chỉ đến các phần tử thiết kế được so khớp. Hợp nhất hoạt động Hợp nhất hoạt động thực hiện khác với hợp nhất các phần tử cấu trúc. Các hành vi khác nhau thường được mô-đun trong các theme riêng biệt, chúng ta nên chỉ ra một tập các hoạt động so khớp khi chúng cần được thi hành cùng nhau. Ví dụ, bạn có các lớp so khớp có các attribute khác nhau, và có một method print()mà in ra các giá trị attribute. Khi các lớp như vậy được tổng hợp, tất cả thông tin đều được in, và vì thế khi print() được thi hành trên class tổng hợp, tất cả các hoạt động print() trên các lớp so khớp đều sẽ thi hành. 41 Khi hợp nhất các hoạt động có tên giống nhau, các hoạt động input được đổi tên (có thể là thêm tiền tố là tên theme của chúng) để tránh rối loạn, và tên ban đầu được sử dụng để tạo biểu đồ tuần tự mà thi hành mỗi operation trong biểu đồ tuần tự. Đây là cách xử lý mặc định cho các operation được so khớp. Xét sự hợp nhất operation trong hình 4-2, khi hợp nhất theme1 và theme2 thì các hoạt động op1() trong cả hai class ClassB được so khớp. Để chỉ ra các hành vi được hợp nhất, một biểu đồ tuần tự được tạo ra để xác định khi mà một yêu cầu thực hiện op1(), hai operation op1() trong các theme cũng được gọi. Các operation input được thay tên để tránh mâu thuẫn tên trong cả hai mô hình class và đặc tả biểu đồ tuần tự của chúng, ở đây các operation thay tên bằng cách thêm tên theme của chúng vào đầu tên operation, op1() trong theme1 được đổi thành Theme1_op1(). Tuy nhiên sự hợp nhất operation mặc định đó không phải lúc nào cũng được yêu cầu, ta có thể tránh hợp nhất bằng một relationship tổng hợp rõ ràng giữa hai operation với nhãn [dontMatch]. Một số operation khác tên nhau, được mô-đun hóa trong các theme riêng biệt nhưng chúng cùng mô tả các hành vi liên quan đến một vấn đề, hoạt động liên quan đến nhau thì chúng ta sẽ nhóm chúng lại để các hoạt động xảy ra cùng nhau, và thi hành chúng một cách tuần tự. Việc đó chính là hợp nhất các hoạt động. Khi các operation được hợp nhất (dù chúng có cùng tên hay không), sự sắp xếp thi hành trong chuỗi các operation so khớp là tạo ngẫu nhiên. Nếu thứ tự thi hành các hoạt động là quan trọng thì biểu đồ tuần tự tương ứng sẽ sắp xếp thứ tự các hoạt động . Bây giờ chúng ta sẽ xem xét vấn đề khi xảy ra xung đột tham số trong hợp nhất operation, hoặc nếu có nhiều operation trả về một giá trị. Trong trường hợp đầu tiên, nguyên tắc chung cho so khớp operation là chúng phải có cùng dấu hiệu kích hoạt. Khi thi hành, các giá trị input cho hoạt động tổng hợp có thể được sử dụng để gọi mỗi hoạt động của so khớp. Có một ngoại lệ cho nguyên tắc này, nếu một trong các operation so khớp có các tham số mà giá trị của chúng được sử dụng trong các operation so khớp khác (với tập các tham số của các operation được gọi), các operation đó có thể xác định là so khớp. Trong trường hợp này bạn phải gắn một biểu đồ tuần tự tới relationship tổng hợp chỉ ra làm thế nào các operation đó được gọi. Nếu không làm thế, các operation không được so khớp. Trong trường hợp thứ hai, sẽ mặc định là giá trị trong operation thi hành cuối cùng được trả về. Nếu bạn muốn hành vi khác trả về giá trị, bạn phải chỉ ra sự xác định hành vi đó trong biểu đồ tuần tự trên relationship tổng hợp. 42 Các phần tử không so khớp Nói chung, các phần tử thiết kế không so khớp với các phần phần tử khác thì được thêm vào thiết kế tổng hợp trong các namespace tương ứng. Cho ví dụ, các class mà không so khớp bất kỳ class nào, các thành phần của nó sẽ không thay đổi trong tổng hợp theme; các attribute mà không so khớp attribute khác trong các class so khớp của chúng thì đơn giản là thêm vào class tổng hợp. .. 4.3.2 Tích hợp override Dùng khi bạn có một phiên bản mới của theme mà cung cấp thêm đặc điểm mới cập nhật của requirements thay đổi với một theme đã tồn tại. Với tích hợp override, bạn có thể chỉ ra một theme ghi đè một theme khác, các phần tử trong theme ghi đè sẽ thay thế các phần tử được so khớp trong theme ghi đè. Các phần tử không được so khớp sẽ được bổ sung vào kết quả tổng hợp. Hình 4-3 Tích hợp ghi đè Hình 4-3 là một ví dụ minh họa. Nhãn Match[name] trên relationship tổng hợp đưa ra một so khớp cho các lớp ClassB từ theme input , các attribute của chúng là a,b và operation của chúng là op1(). Attribute a trong theme tổng hợp là public, giống như được xác định trong overriding theme (Theme1). Ngoài ra, hành vi của op1() trong theme kết quả giống như trong Theme1, biểu đồ tuần tự cho op1() trong Theme2 đã được thay thế với biểu đồ tuần tự cho op1() trong Theme1. 43 Trong tích hợp override mũi tên của quan hệ tổng hợp đi từ theme bị ghi đè sang theme ghi đè. Các nguyên tắc ghi đè Các nguyên tắc cho xác định relationship tổng hợp với tích hợp override gồm có : -Một relationship tổng hợp với tích hợp override phải là 1-1. Hay nói cách khác, một phần tử thiết kế chỉ ghi đè một phần tử thiết kế khác. -Một phần tử thiết kế chỉ được ghi đè một lần, trong một đặc tả tổng hợp đơn. -Các phần tử thiết kế ghi đè và bị ghi đè không tham gia trong các tổng hợp merge và override nào khác. Điều này đảm bảo không có sự rối rắm với tham chiếu trong kết quả tổng hợp. 4.3.3 Kết hợp các phương pháp tích hợp Các kiểu tích hợp có thể sử dụng trong cùng đặc tả tổng hợp. Nguyên tắc chung cho bất kỳ kiểu tổng hợp nào: đầu tiên phải xác định một relationship tổng hợp giữa các theme được tổng hợp. Sau đó có thể làm mịn hơn so khớp và tích hợp với bổ xung thêm các relationship tổng hợp giữa các thành phần của theme container. Một relationship tổng hợp được chỉ ra giữa các phần tử container áp dụng cho tất cả các thành phần bên trong container, trừ các relationship tổng hợp sâu hơn được chỉ ra giữa các thành phần bên trong các container so khớp. Do vậy, đặc điểm tích hợp của các relationship tổng hợp không giống nhau, khi áp dụng merge hay override là phải rõ ràng. Khi chỉ ra tích hợp overrride giữa các phần tử trong các theme, có một qui tắc ngầm định rằng đầu tiên phải lựa chọn các theme tham gia tổng hợp. Xác định relationship tổng hợp mức theme với tích hợp merge, và sau đó xác định các yêu cầu tích hợp ghi đè tại mức phần tử chỉ được xác định giữa các phần tử thuộc hai theme đó. 4.4 Giải quyết xung đột Với tích hợp merge, các phần tử được so khớp như các attribute và các class xuất hiện trong kết quả một lần, sẽ xảy ra xung đột nếu như các phần tử được so khớp có sự đặc tả khác nhau. Vì vậy chúng ta cần có một phương pháp để giải quyết các xung đột trong đặc tả của các phần tử được tích hợp. 44 Theme/UML cung cấp ba kỹ thuật khác nhau cho phép bạn thực hiện khi xung đột phát sinh: xác định rõ ràng các giá trị cho một xung đột cụ thể; xác định giá trị mặc định cho các cấu trúc thiết kế cụ thể; và xác định độ ưu tiên của theme. 4.4.1 Explicit values Cách cơ bản nhất để giải quyết xung đột giữa hai phần tử thiết kế là đặc tả kết quả nên nói một cách rõ ràng. Trong ví dụ hình 4-4, xung đột sinh ra do sự khác nhau về đặc tả tầm nhìn. ClassB trong Theme1 coi attribute a là public, trong khi ClassB trong theme2 cho rằng attribute a là private. Trong nhãn “resolve” trên relationship tổng hợp chúng ta nói rõ ràng rằng ClassB.a có tầm nhìn là private. Hình 4-4 Giải quyết xung đột với giá trị rõ ràng Bất kỳ đặc điểm cấu trúc nào cũng có khả năng xung đột, ví dụ, thuộc tính có tên, kiểu, giá trị khởi tạo, … Bạn có thể yêu cầu giá trị cho tất cả nhãn nếu cần thiết. Nếu có rất nhiều xung đột thì ta không nên chọn cách giải quyết này. Hai kỹ thuật giải quyết tiếp theo đưa ra câu lệnh tổng quát hơn khi xung đột xảy ra. 4.4.2 Giá trị mặc định Ta có thể chỉ ra giá trị mặc định cho tất cả các phần tử của một kiểu cụ thể được sử dụng chỉ trong một sự kiện xung đột. Ví dụ, khi có xung đột trong một tầm nhìn của attribute ta có thể chỉ ra nó là private, hoặc khi có xung đột cho tầm nhìn class thì ta có thể chỉ ra nó là public…. Hình 4-5 minh họa một ví dụ mà có xung đột attribute a trong các ClassB. 45 Hình 4-5 Giải quyết xung đột với giá trị mặc định Trong nhãn “resolve” trên relationship tổng hợp, chúng ta nói rằng với sự kiện xung đột cho bất kỳ tầm nhìn của attribute nào thì nó cũng xác định là private. Trong trường hợp này ClassB.a trong kết quả tổng hợp có tầm nhìn là private. Bạn có thể chỉ ra giá trị mặc định cho tất cả các attribute của một construct, nhưng không có khả năng chỉ ra giá trị mặc định cho các thuộc tính như: name, kiểu. Giá trị mặc định không sử dụng cho thuộc tính mà xác định một phần tử thiết kế (miêu tả phần tử theo hướng vật chất). Nếu cần giải quyết một xung đột thuộc tính như vậy thì chỉ ra giá trị rõ ràng (hoặc theo độ ưu tiên theme) là cách giải quyết. 4.4.3 Theme Precedence Nếu một theme có độ ưu tiên hơn những cái khác, nếu có xung đột xảy ra khi so khớp phần tử, đặc tả trong theme với độ ưu tiên cao nhất sẽ được sử dụng trong kết quả. Hình 4-6 Giải quyết xung đột với độ ưu tiên 46 Hình 4-6, relationship tổng hợp có nhãn “1.prec” , ta nói trong sự kiện xung đột giữa các đặc tả của các phần tử so khớp, đặc tả xác định trong theme2 sẽ được sử dụng trong kết quả tổng hợp. ClassB.a có tầm nhìn là private. Số thứ tự trong nhãn ưu tiên chỉ ra một sự sắp xếp cho độ ưu tiên. Khi tổng hợp nhiều theme, có thể chỉ ra theme có độ ưu tiên hơn các theme khác, với độ ưu tiên 1 là cao nhất. Đặc tả từ theme với độ ưu tiên cao nhất sẽ được sử dụng trong kết quả tổng hợp. 4.5 Chỉ ra binding cho Theme aspect Khi tổng hợp các theme base với theme aspect, các theme thường được tổng hợp với tích hợp merge. Chúng ta sẽ gắn nhãn bind[] trên Theme/ UML's relationship. Với nhãn bind[] cơ bản là liệt kê tất cả các kích hoạt mà so khớp với mỗi template trong theme aspect. Hình 4-7 minh họa một ví dụ đơn giản. Hình 4-7 Ràng buộc triggers với aspect tmeplates Theme1 trong hình 4-7 có một khối hành vi crosscutting (op2()) mà thi hành sau bất kì kích hoạt nào. Kích hoạt được mô tả trong thiết kế là một operation template op1(). Gắn ràng buộc bind xác định hai kích hoạt trong Theme2 base: x() từ ClassC và o() từ ClassE. Thiết kế này chỉ ra rằng, khi một trong hai ClassC.x() hoặc ClassE.o() xảy ra thì op2() trong theme aspect cũng được thi hành sau đó. Hình 4-8 minh họa cách Theme/UML mô hình kết quả của theme aspect được bind với theme base. Một biểu đồ tuần tự được tạo chỉ ra hành vi mà xảy do các kích hoạt từ theme base. 47 Hình 4-8 Hoạt động base kích hoạt hành vi aspect Khi chỉ ra một operation trong theme base so khớp với một operation template trong theme aspect, chính là so khớp các class tương ứng. Trong kết quả của sự so khớp này, các class được hợp nhất và các class được so khớp trong theme base được đổi tên để tránh xung đột. Ví dụ như hình 4-7 và hình 4-8, ClassB được hợp nhất với cả hai ClassC, ClassE. Bởi vì chỉ phần tử trong class có template mới có thể tham chiếu đến các phần tử khác trong class đó, nên trong các class được hợp nhất bằng tham chiếu sẽ không có sự rối loạn. Chỉ các methods trong ClassB mới có thể gọi methods trong ClassB va tham chiếu đến các attribute trong ClassB, và các tham chiếu map tới ClassC và ClassE tương ứng trong kết quả. Methods trong ClassB có thể thi hành các methods khác trong các class khác ở trong aspect, với điều kiện là các class khác không có khả năng hợp nhất với nhiều class khác. Các operation mà sẽ bind tới các template trong theme log được chỉ ra bằng relationship tổng hợp gắn nhãn bind[]. Tập template biểu thị các biểu đồ tuần tự khác nhau của các hành vi trong ngoặc trong nhãn bind , có thể xác định một hay nhiều phần tử thực để bind tới các template đó trong các ngoặc . Chú ý là có nhiều operation để chỉ ra một template thì chúng được nhóm trong ngoặc { }. Chúng ta nên tổng hợp các theme base trước, sau đó tổng hợp với các theme crosscutting. 48 Hình 4-9 Bind log crosscutting Trong hình, theme log chỉ có một tập template, tương ứng với hoạt động trong theme base được ghi log. Ngoặc trong nhãn bind chỉ ra rằng có một tập các hoạt động mà sẽ được ghi log: expression.check(..), expression.asString(..), expression.evaluate(..). Không giới hạn số template trong một chuỗi hành vi. Nhưng template đầu tiên trong nhóm của hộp template phải miêu tả operation thay thế mà kích hoạt chuỗi hành vi. Tương ứng, operation thay thế đầu tiên trong bind[] sẽ là một trong các hành vi kích hoạt. Mẫu thiết kế Observer là một ví dụ cho template trong một chuỗi các sự kiện. Trong mẫu Observer có các subjects (đối tượng) và observers (người quan sát). Observers ghi những chú ý về thay đổi trạng thái của các subjects. Khi subject thay đổi trạng thái (một Theme/UML template), một sự kiện được send tới observers (cũng là một template). Hình 4-10 minh họa một hộp template của thiết kế theme crosscutting Observer, chứa các template cho ba chuỗi hành vi: observer crosscutting được kích hoạt khi thay đổi trạng thái trong object, khi một observer khởi đầu, và observer chấm dứt sự quan tâm một subject. 49 Hình 4-10. Observer template. Chuỗi hành vi thay đổi trạng thái có hai template : aStateChange(..) và update(), khi subject thay đổi trạng thái sẽ kéo theo hành vi update() của người quan sát, các hành vi này được so khớp và đưa vào biểu đồ tuần tự. Như vậy, một biểu đồ tuần tự được tạo cho mỗi tập operation thay thế liên quan với một chuỗi hành vi (mỗi nhóm hoạt động trong ngoặc trong template box sẽ tương ứng với một biểu đồ tuần tự). bind[ ] Nếu có nhiều trạng thái thay đổi được quan sát, ngoặc { } có thể sử dụng để nhóm các operation mà thay thế cho một template. Ví dụ: bind[ < { subject._do_aStateChange1(),subject._do_aStateChange2()}, observers.update() > ] Trong ví dụ này, hai biểu đồ tuần tự được tạo để chỉ điều xảy ra khi thi hành hai hoạt động thay đổi trạng thái khác nhau của subject. Trong cả hai trường hợp, hành vi 50 update() của observers cũng được thi hành. Làm mịn cú pháp hơn với ngoặc { } để nhóm các operation trong cùng lớp, ta có thể viết lại nhãn bind trên như sau: bind[ < { subject.{_do_aStateChange1(), _do_aStateChange2()}}, observers.update() > ] Nói chung, khi nhiều operation thay thế template đầu tiên (template miêu tả sự kích hoạt của hành vi crosscutting), thì sẽ có một biểu đồ tuần tự được tạo ra cho mỗi cái. Nếu không muốn observers.update() thực thi trong mọi thể hiện của thay đổi trạng thái, các nhóm phải được xác định rõ ràng, chúng ta không cho phép có nhiều thay thế cho các template tiếp sau hoạt động kích hoạt đầu tiên. Chúng ta cần xác định nhiều bindings lồng nhau trong một tập . Ví dụ, tất cả operation bắt đầu với add của object class mà kích hoạt hành vi observers.addUpdate() được bao trong một ngoặc < > con, trong khi _do_aStateChange1() và _do_aStateChange2() kích hoạt thi hành của observers.update() được bao trong một ngoặc con, cả hai ngoặc con đó được đặt trong một ngoặc cha để chỉ ra hai hành vi khác nhau được kích hoạt cho template thứ hai trong tập template thay đổi trạng thái của object. bind[ < { subject.{_do_aStateChange1(),_do_aStateChange2()}},observers.update() > > ] Với mỗi nhóm , template đầu tiên trong một nhóm tuần tự mà kích hoạt hành vi crosscutting có thể có nhiều bindings, nhưng các template tiếp theo thì không. Không cần thiết phải luôn có danh sách rõ ràng các kích hoạt trong theme base. Theme/UML cũng cấp các cách thức chỉ ra nhiều phần tử thay thế mà không cần đặt tên rõ ràng, kể cả một số operation phức. Bảng 4-1 Chỉ ra nhiều phần tử. Cấu trúc Ý nghĩa * Tất cả các phần tử cấu trúc sẽ là phần tử thay thế. Ví dụ, ClassName.*() thỏa mãn với tất cả các operation trong 51 ClassName. Khi sử dụng *.* (để thay thế cho một operation template) thỏa mãn với mọi operation trong mọi class trong theme base. cc* Giống với *, nhưng các kí tự đầu của phần tử thay thế phải giống như kí tự được chỉ ra trước *. Ví dụ Player.set* (để thay thế cho một operation template) thỏa mãn với mọi operation mà bắt đầu với “set” trong Player class *cc Tương tự như cc*, nhưng các kí tự cuối của phần tử thay thế phải giống với các kí tự chỉ ra sau *. Meta:property=value Sử dụng nhãn đặc tả, xác định phần tử thay thế bằng cách đưa ra yêu cầu giá trị của metaproperties của construct. () AND () Tất cả các phần tử thỏa mãn trong các toán hạng sẽ thay thế mẫu () AND NOT () Toán tử AND NOT bao gồm tập các operation mà thỏa mãn toán hạng đầu và không bao gồm tập operation thỏa mãn trong toán hạng sau 52 Chương 5 Xây dựng hệ thống điện thoại với phương pháp Theme 5.1 Tóm tắt về dự án: Ngày nay, điện thoại không chỉ để thông tin liên lạc mà còn xem tivi, nghe nhạc, duyệt web, thoại video, gửi hình ảnh-âm thanh, định vị GPS, rút tiền từ máy ATM, thanh toán mua hàng từ máy bán hàng tự động… Mọi việc từ chia sẻ thông tin đến phục vụ các nhu cầu giải trí đều nằm gọn trong một chiếc điện thoại . Điều đó cho ta thấy tầm ảnh hưởng vô cùng to lớn của mobile trong cuộc sống. Công nghệ xây dựng các ứng dụng cho hệ thống mobile đang rất phát triển. Đi kèm với nó là một loạt các công nghệ và kĩ thuật để giúp bạn có thể xây dựng và phát triển các ứng dụng mobile, như J2ME của Java, hay .NET Mobile. Trong phạm vi nghiên cứu của khóa luận này em chỉ đề cập tới việc phân tích và ứng dụng kĩ thuật aspect để xây dựng các đặc điểm trên hệ thống mobile cơ bản mà bất cứ một chiệc điện thoại cầm tay nào cũng có, như dịch vụ SMS, nghe nhạc hay chơi game... xây dựng ứng dụng với aspectJ. + Phạm vi dự án : ứng dụng giả lập chạy trên PC. + Đối tượng sử dụng: Là người dùng tương tác trực tiếp với ứng dụng mobile giả lập. 5.2 Phân tích yêu cầu dự án Trong phần này chúng ta sẽ ứng dụng cách sử dụng theme với việc phân tích và thiết kế các đặc điểm của hệ thống điện thoại. Chúng ta sẽ không đặt trọng tâm vào các giao tác như là xử lý cuộc gọi… mà chủ yếu xem xét kĩ tới các đặc điểm của hệ thống điện thoại, cụ thể là: cuộc gọi thoại (voice call), dịch vụ tin nhắn ngắn (SMS), một máy nghe nhạc đa phương tiện (media player), và một ứng dụng game (game application). Bảng 5-1. Danh sách các requirement của hệ thống. Đặc Điểm Requirements (Các yêu cầu) Menu R1: menu chứa một vài tùy chọn: làm một cuộc gọi thoại, viết một tin nhắn, sử dụng trình nghe nhạc, chơi một trò chơi. 53 R1: The menu consists of several options: make a voice call, write an SMS, use the media player, play a game. R2: Người dùng có thể cuộn menu và lựa chọn một mục để bắt đầu. R2: A user can scroll through the menu and select an item to start. Alert and Rings (Cảnh báo và chuông) R3: Chuông báo được sử dụng để làm tín hiệu khi một cuộc gọi thoại đến R3: Ringing is used to signal an incoming voice call R4: Hộp cảnh báo được sử dụng để làm tín hiệu khi một tin nhắn tới. R4: Alerts are used to signal an incoming SMS R5: khi cảnh báo và chuông xảy ra, những âm thanh khác như (media player, voice call, âm thanh của game) được chuyển về trạng thái mù âm nhưng không bị dừng lại R5: when alerts and rings occur, other audio (media player, voice call. game sound) is momentarily muted but not paused. Voice Call R6: khi một cuộc gọi thoại xảy ra, những hoạt động khác như (media player, game, chỉnh sửa tin nhắn) đều bị dừng lại, và trạng thái của chúng được lưu lại, để có thể phục hồi khi cuộc gọi kết thúc. R6: when a voice call occurs, other activities (media player, game, SMS edit) are paused, and their state saved, to be resumed when the call ends. SMS R7: Người dùng có thể gửi và chỉnh sửa một tin nhắn từ trong ứng dụng SMS. R7: A user can send and edit an SMS from within the SMS application Game R8: Người dùng có thể chơi, tạm dừng, lưu trạng thái và thoát khỏi một game. R8: A user can play, pause, save, and exit a game session. Media Player R9: Trình nghe nhạc có các chức năng: chơi audio, thu âm audio, radio, chơi memo và thu âm memo R9: The media player has several functions: play audio, record audio, radio, memo play. and memo record R10: Trình nghe nhạc có thể bắt đầu, dừng, tạm dừng và resume tất cả các chức năng ở trên. 54 R10: The media player can start, stop, pause, and resume all those functions 5.2.1 Xác định các theme ban đầu Dựa vào tên các chức năng, và các hành động trong tập requirement để tìm các theme tiềm năng. Tập theme ban đầu được chọn: Menu voice call SMS media player game scroll menu start ring signal voice call alert game sound mute pause SMS eidt Save Resume Send Edit play exit play audio record audio radio memo play memo record stop Hình 5-1 chỉ ra khung nhìn relationship cho các theme ta đã lựa chọn được ở trên. Các theme được gắn với các requirement liên quan. 55 Hình 5-1 Khung nhìn relationship cho tập theme ban đầu. 5.2.2 Làm mịn tập theme 5.2.2.1 Phân tách theme Một số theme có ý nghĩa hàm chứa rất chung chung, liên quan đến các chức năng riêng biệt của các ứng dụng trong hệ thống không liên quan đến nhau. Cần phải tách các theme đó thành các theme mới, và gắn các theme đó với requirement phù hợp. -Theme save gắn với R6, R8, cùng nói về việc lưu trữ trạng thái nhưng ứng với hai requirment thì theme save này có ý nghĩa khác nhau. Với R6, theme save sẽ lưu lại trạng thái hoạt động của các đối tượng (Media Playger, game, SMS) khi thực hiện hoạt động nói chuyện voice call. Trong R8, theme save ở đây nói về việc lưu trữ lại trạng thái hoạt động của game đang chơi. Cần phải tách theme save này thành hai theme là : audio-save ứng với R6, và game-save ứng với R8. -Theme pause được phân tách thành 3 theme :audio-pause gắn với R6, game- pause gắn với R8, và media-pause gắn với R10, 3 theme con này đều nói về trạng thái tạm dừng hoạt động của các đối tượng, nhưng với audio-pause là trạng thái bị dừng lại 56 để cho một hành động có mức độ ưu tiên cao hơn hoạt động trước, còn game-pause và media-pause nói về chức năng của từng ứng dụng trong hệ thống mobile. -Theme start được phân tách thành hai theme :media-start gắn với R10, và menu- start gắn với R1. -Theme signal được phân tách ra thành hai theme : signal call gắn với R3 và signal sms gắn với R4. Hình 5-2. Khung nhìn quan hệ sau khi apply các theme mới Bảng 5-1. Danh sách các tên theme mới sau khi đã được phân tách như trên. Các theme ban đầu Theme mới Save Audio-save (R6), game-save (R8). Pause Audio-pause (R6), game-pause (R8), media-pause (R10). Start Media-start (R10), menu-start (R2). Signal Signal call (R3), signal sms (R4). 57 5.2.2.2 Group theme Một số theme là các chức năng cho một đặc điểm của hệ thống, chúng có liên quan đến nhau khi hoạt động. Các theme như vậy sẽ được nhóm lại với nhau. Thao tác nhóm theme sẽ được dựa trên các đặc điểm chính của hệ thống. -Ring và signal call là các theme liên quan đến gọi điện thoại, ring là tín hiệu cho một cuộc gọi đến. Ring và signal được nhóm trong một theme chính là theme voice call. -Tin nhắn SMS có thể được edit, send; tín hiệu một tin nhắn đến là alert, ta nhóm các theme: edit, send, signal sms và alert vào một nhóm, với theme chính là SMS. Các chức năng đối với ứng dụng game là: play, pause, save. Các theme: game- play, game-pause, game-save được nhóm lại với nhau, với theme chính là Game. -Thành phần của media player gồm có : radio, audio, memo; các chức năng cho media player là: stop, start, pause và resume. Ta có thể nhóm các theme liên quan đến media player vào một theme chính là Media player, các theme con là: radio, play audio, record audio, memo play, memo record, media-start, media-pause, media- resume . -Menu có thể được cuộn và chọn một item để bắt đầu. Ta nhóm các theme: scroll, slect, menu-start vào một nhóm, với theme chính là Menu. -Các theme còn lại mà chưa được nhóm lại là: mute, audio-resume, audio-pause, audio-save. Chúng đều có liên quan đến sự thay thế các hoạt động đang thực hiện trong hệ thống bằng một số hành vi khác. Ta nhóm chúng vào một theme mới, là preempt. Các requirements gắn với các theme con là R5, R6 bây giờ được gắn với theme chính preempt. Bảng 5-2 Theme và tập theme con Tên theme chính Các theme con Game game-play, game-pause, game-save. media player radio, play audio, record audio, memo play, memo record. Menu scroll, select, start. Sms send, edit, signal sms, alert. Voice call signal call, ring. 58 Preempt (new theme) mute, audio-resume, audio-pause, audio-save. Hình 5-3 mô tả khung nhìn relationship của hệ thống sau khi nhóm các theme. Các requirement gắn với các theme con ban đầu, bây giờ được gắn tới các theme chính chứa chúng. Hình 5-3. Refine các theme. 5.2.2.3 Xác định theme crosscutting: Thông qua mối quan hệ chia sẻ khái niệm để tìm theme crosscutting trong hệ thống.Từ khung nhìn quan hệ trong hình 5-3, có 3 requirement mà được tham chiếu tới các theme khác nhau trog hệ thống, là: R1, R5, R6. - R1: “The menu consists of several options: make a voice call, write an SMS, use the media player, play a game”, menu chứa đựng một vài tùy chọn : làm một cuộc gọi,viết một tin nhắn,sử dụng trình nghe nhạc,và chơi một game”, 59 Qui tắc đầu tiên trong cách xác định là “split up if possible-phân tách nếu có thể”. Không thể phân tách requirement R1 này được, requirement này liệt kê ra các thành phần của menu, không thể viết lại R1 thành các requirement nhỏ hơn mô tả các thành phần tương ứng với các theme cùng chia sẻ được. Qui tắc thứ hai : “Dominance means association-Chi phối với nghĩa là giao kết”, theme menu sẽ chi phối requirement này, menu sẽ chứa các thành phần mà R1 liệt kê, theme menu là theme cân biết vè R1 nhiều nhất. Qui tắc thư 3: “Base trigger aspect”, ở đây chúng ta đã xác định được theme menu là aspect , vì nó chi phối requirement này. Có một loạt các theme cùng được tham chiếu trong R1 như : voice call, sms…. nhưng không có mối quan hệ base-trigger nào xảy ra ở đây. Theme menu sẽ liệt kê các thành phần đặc điểm của hệ thống để người dùng có thể tương tác và sử dụng, nó có mối quan hệ has-a với các theme chia sẻ. Do đó R1 đươc postponce trì hoãn và có thể thiết kế theme menu này giống như là theme chia sẻ. kết luận rằng: R1 được chi phối bởi theme menu, nhưng menu không phải là một crosscutting. -R5: “When alerts and rings occur, other audio (media player, voice call, game sounds) is momentarily muted, but not paused - khi cảnh báo và chuông xảy ra, những âm thanh khác như (media player, voice call, âm thanh của game) được chuyển về trạng thái tắt âm tạm thời nhưng không bị dừng lại” Thử phân tách R5 thành: “When alerts and rings occur, other audio (media player, voice call, game sounds) is momentarily muted”; và “ audio is momentarily muted, but not paused” . Ta thấy ý nghĩa hai requirement mới lại quay về chính requirement R5 ban đầu. R5 không thể phân tách thành nhỏ hơn được. Xét qui tắc thứ hai- dominated, xác định theme chi phối R5. Preempt là theme chính chứa các theme: theme mute, audio-pause, chúng liên quan tới các các hành vi được mô tả trong R5, các theme chia sẻ R5 còn lại: voice call và msm hầu như không cần quan tâm đến hành vi mô tả trong R5. Vì vậy, preempt là theme chi phối R5. Xét qui tắc thứ 3, preempt bị kích hoạt bởi hai tình huốn: alert và ring xuất hiện, khi alert hoặc ring xảy ra thì hoạt động hiện tại trong hệ thống bị tắt âm (mute) tạm thời. Thêm vào đó, requirement này mô tả nhiều hơn một vị trí nơi mà preempt được kích hoạt (trong media, game, voice call) nên kết luận rằng preempt là một rosscutting. - R6: “When alerts and rings occur, other audio (media player, voice call, game sounds) is momentarily muted, but not paused - khi một cuộc gọi thoại xảy ra, những hoạt động khác như (media player, game, chỉnh sửa tin nhắn) đều bị dừng lại, và trạng 60 thái của chúng được lưu lại, để có thể phục hồi khi cuộc gọi”, chúng ta có thể khẳng định được luôn R6 không thể phân tách và được chi phối bởi theme preempt, R6 mô tả thêm một tình huống nữa nơi mà preempt bị kích hoạt, khi voice call xảy ra. Từ hai requirement R5, R6 ta xác định được chung một crosscutting là preempt Hình 5-4: khung nhìn crosscutting cho theme preempt 5.3 Thiết kế các theme 5.3.1 Phân tích UseCase Use case của toàn hệ thống: Hình 5-5. Use case hệ thống. Bảng các use case trong hệ thống: Bảng 5-3 Các use case trong hệ thống. MangeCall UC01 61 ManageGame UC02 ManageSMS UC03 Manage MediaPlayer UC04 Chi tiết các use case xem trong phần Phụ lục 5.3.2 Thiết kế theme Có 5 theme chính : menu, game, media , sms, voice call. Từ các khung nhìn individual của các theme, xây dựng biểu đồ cấu trúc, seuqence cho các theme. 5.3.2.1 Menu theme Hình 5-6: Khung nhìn individual của menu theme 62 Hình 5-7 thiết kế cấu trúc cho menu theme 5.3.2.2 Thêm audible theme Trong quá trình thiết kế , ta nhận thấy việc điều chỉnh âm thanh sẽ phục vụ cho rất nhiều theme (chức năng) trong hệ thống. như media, hay game. Thêm lớp audible vào một theme mới Audible để cho các lớp khác có liên quan đến chỉnh sửa âm thanh kế thừa nó. Hình 5-8. Thiết kế cấu trúc cho theme Audible. 63 5.3.2.3 Sms theme Hình 5-9. Khung nhìn individual của SMS theme. Hình 5-10. Cấu trúc theme SMS. 64 Hình 5-11. Biểu đồ tuần tự Create SMS. Hình 5-12. Biểu đồ tuần tự editSMS 65 1.1.1.1 Media Player theme Hình 5-13. Khung nhìn individual của theme Media player. 66 Hình 5-14. Cấu trúc theme MediaPlayer. Hình 5-15. Biểu đồ tuần tự recordAudio. 67 Hình 5-16. Biểu đồ tuần tự PlayAudio. Hình 5-17. Biểu đồ tuần tự PauseAudio. 68 Hình 5-18. Biểu đồ tuần tự StopAudio. Hình 5-19. Biểu đồ tuần tự ResumeAudio . 69 Hình 5-20 . Biểu đồ tuần tự PlayRadio. Hình 5-21. Biểu đồ tuần tự stopRadio. 70 Hình 5-22. Biểu đồ tuần tự resumeRadio. Hình 5- 23. Biểu đồ tuần tự PlayMemo. 71 Hình 5-24. Biểu đồ tuần tự PauseMemo . Hình 5-25 . Biểu đồ tuần tự StopMemo 72 Hình 5-26. Biểu đồ tuần tự ResumeMemo . Hình 5- 27. Biểu đồ tuần tự RecordMemo. 73 5.3.2.4 voiceCall theme Hình 5-28. Khung nhìn individual của theme VoiceCall. Hình 5- 29. Cấu trúc theme VoiceCall. 74 Hình 5-30. Biểu đồ tuần tự thực hiện cuộc gọi với số phone lưu trong danh bạ. Hình 5- 31. Biểu đồ tuần tự thực hiện cuộc gọi với số phone được nhập vào. 75 5.3.2.5 Game theme Hình 5- 32. Khung nhìn ndividual của game theme Hình 5- 33. Cấu trúc theme Game. 76 Hình 5-34 . Biểu đồ tuần tự chơi game. Hình 5-35 . Biểu đồ seuqence tạm dừng chơi game. 77 Hình 5-36. Biểu đồ tuần tự lưu game. Hình 5-37. Biểu đồ seuquence thoát khỏi game. 78 5.3.2.6 Thiết kế theme preempt Hình 5-38. Khung nhìn individual của crosscutting Preempt. Hình 5-39 . Thiết kế cho theme preempt. 79 HighPriority là các đối tượng trong theme base mà kích hoạt aspect: voice call, và SMS. Các hoạt động của lớp này là : start() - thay thế cho hoạt động đàm thoại, sound() - thay thế cho hoạt động xuất hiện một alert hay ring, và các hành động thực của các kích hoạt tương ứng là: _do_start(), do_sound(). Preempted là các đối tượng có hành vi cắt ngang các hành vi kích hoạt, trong lớp preempted có các phương thức: pause(), save(), resume(), restore(), mute(). Nó chính là đối tượng: Audible và Saveable. Tập template thứ nhất ứng với lược đồ tuần tự sound. Hành vi kích hoạt aspect là HighPriority.sound, bao gồm hai hành vi VoiceCall.ring() và SMS.alert(). Đối tượng đang thực hiện bị tắt âm, Preempted.mute(). Hoạt động kích hoạt được thi hành, HighPriority. _do_sound(). Khi hoạt động kích hoạt hoàn thành, đối tượng bị thay thế được trả lại như cũ. Tập template thứ hai ứng với hành vi kích hoạt voice call, sơ đồ tuần tự start. Hành vi kích hoạt HighPriority.start() bắt đầu xảy ra, đối tượng đang thực hiện bị dừng lại, Preempted.pause(), và sau đó được lưu lại, Preempted.save(). Và hành vi kích hoạt được thực hiện, HighPriority._do_start. Khi hành vi kích hoạt hoàn thành, đối tượng bị thay thế được trả về trạng thái cũ. 5.4 Tổng hợp theme Sử dụng tích hợp hợp nhất giữa các theme so khớp. Đầu tiên chúng ta sẽ tổng hợp các theme base. 80 Hình 5-40. Tổng hợp theme base. Tổng hợp các theme base thành một theme “Phone”, bằng cách so khớp các phần tử cùng tên. Các class cùng tên menu, audible, saveable được hợp nhất thành mỗi class chính tương ứng trong theme kết quả. Các sơ đồ tuần tự trong các theme base được bổ sung vào thiết kế của theme tổng hợp. Theme kết qủa sau khi so khớp cấu trúc: 81 Hình 5-41. Theme tổng hợp của các theme base. Bind theme base với crosscutting: Bind kết quả tổng hợp các theme base với theme crosscutting. Với nhãn bind: Bind[ ] 82 Hình 5- 42. Bind theme crosscutting với phone theme. Theme kết quả của bind crosscutting với theme base được thể hiện trong hình 5- 43. Các class trong các theme base chỉ ra cho nhãn bind so khớp với class template của crosscutting. Mô hình theme tổng hợp có tên Telephone. 83 Hình 5-43. Theme kết quả của bind crosscutting với các theme base Sau khi tổng hợp theme preempt với các theme base, ta có ba biểu đồ tuần tự ứng với ba hành vi kích hoạt : sd alert ( hình 5-44), sd ring (hình 5-45) và sd connect (hình 5-46). Tập biểu đồ tuần tự cho hệ thống gồm có ba biểu đồ này, và bổ sung thêm tập biểu đồ tuần tự trong các theme “ Phone” mà tổng hợp các base theme . 84 Hình 5-44. Biêu đồ tuần tự cho alert. Hình 5-45. Biểu đồ tuần tự cho cuộc gọi đến. 85 Hình 5-45. Biểu đồ tuần tự cho cuộc gọi xảy ra. 86 Kết luận Sau khi nghiên cứu về AOP, em đã nắm được những đặc điểm, thuật ngữ cơ bản của AOP. Em đã thiết kế một hệ thống điện thoại đơn giản theo hướng aspect bằng cách áp dụng phương pháp theme. Và viết một chương trình demo nhỏ cho hành vi crosscutting trong hệ thống, sử dụng ngôn ngữ aspectJ mở rộng của ngôn ngữ Java. 87 Phụ lục Các user case cho xây dựng hệ thống điện thoại trong chương 5. Hình 5-46. UC01- Manage Call Bảng 5-4. Use case Manage Call Use Case Name Manage Call Use Case Number UC01 Brief Descrition - Người dùng sử dụng chức năng này để quản lý việc gọi điện thoại. Flow of Events - Người dùng lựa chọn mục “Make a call”từ menu chính. Basic Flow - Hệ thống sẽ đưa ra giao diện của voice call. Người dùng có thể chọn: +Người dùng nhập số điện thoại cần gọi. + Tìm số điện thoại được lưu trong máy. -Người dùng ấn nút gọi điện để kết nối. Alternative Flows Exit Options -Ấn nút “end call” . Special Requirements 88 Pre Requirements Người dùng đang ở menu chính của hệ thống. Post Condition -Gọi tới một số điện thoại đã chọn. Hình 5-47. UC02- Manage Game Bảng 5-5. Use case quản lý game. Use Case Name Manage Game Use Case Number UC02 Brief Descrition - Người dùng sử dụng chức năng này để chơi game. Flow of Events - Người dùng chọn một game để chơi. Basic Flow -Trong danh sách game người dùng chọn một game rồi ấn play để chơi. -Hệ thống tải game người dùng chọn. -Người dùng bắt đầu chơi game, và có thể có các tùy chọn: pause game, save game, exit game, play game. Alternative Flow Exit option -Người dùng chọn exit game. 89 Special Requirements Pre Requirements Người dùng đang ở menu chính của hệ thống. Post Condition Chơi một game. Hình 5-48: UC04 - Manage SMS 90 Bảng 5-6: Use case Manage SMS Use Case Name Manage SMS Use Case Number UC03 Brief Descrition - Người dùng sử dụng chức năng này để quản lý SMS: Create new sms, edit sms. Flow of Events - Người dùng chọn mục SMS từ menu chính. Basic Flow -Hệ thống hiển thị giao diện SMS, người dùng tùy chọn tạo SMS mới hoặc edit SMS. Exit option -Người dùng chọn tạo SMS mới: +Trình soạn thảo SMS hiển thị. +Người dùng viết tin nhắn và ấn nút send. +Giao diện chọn người nhận tin nhắn xuất hiện. +Người dùng có thể chọn một số điện thoại đã lưu trong máy hoặc nhập từ bàn phím. Rồi ấn Ok. +Hệ thống hiển thị thông báo đã gửi. -Người dùng chọn edit một SMS có sẵn: +danh sách các SMS trong máy hiển thị. +Người dùng kích chọn một tin. +Tin nhắn được chọn load vào trình editor, và người dùng có thể edit. + Người dùng chọn save SMS, hiển thị thông báo đã save SMS. Special Requirements Pre Requirements -Người dùng đang ở menu chính của điện thoại. 91 Post Condition Gửi một SMS hoặc edit một SMS. Hình 5-49: Use case Manage MediaPlayer Bảng 5-7: Use case Manage MediaPlayer Use Case Name Manage MediaPlayer Use Case Number UC04 Brief Descrition - Người dùng sử dụng chức năng này để quản lý MediaPlayer : như play audio, record audio… Flow of Events - Người dùng chọn mục “Media player” từ menu chính. 92 Basic Flow Hệ thống hiển thị menu media gồm ba tùy chọn media : memo, radio, audio. -Người dùng chọn audio. Hệ thống hiển thị tùy chọn play audio hoặc ghi audio. +người dùng tùy chọn play audio :  Danh sách các file audio hiển thị .  Người dùng chọn một file rồi ấn nút start để nghe.  Hệ thống kiểm tra kiểu của file được chọn có được hỗ trợ không. Nếu có, thì file bắt đầu được chơi.  Sau đó họ có thể tùy chọn stop, pause và save media và resume media. + người dùng tùy chọn record ghi một audio mới:  Hiển thị giao diện media với chức năng ghi audio.  Người dùng ấn nút start để bắt đầu ghi.  Ghi xong thì người dùng chọn nút save để lưu lại. -Người dùng chọn nghe Radio:  Danh sách các kênh radio hiển thị .  Người dùng chọn một kênh rồi ấn nút start để nghe.  Nếu người dùng đang ở trong vùng phủ sóng của kênh đã chọn thì radio được phát.  Sau đó người dùng có thể tùy chọn stop và resume radio. -Người dùng chọn memo. Hệ thống hiển thị tùy chọn play memo hoặc ghi memo. +người dùng tùy chọn play memo :  Danh sách các file memo hiển thị .  Người dùng chọn một file rồi ấn nút start để nghe.  Sau đó họ có thể tùy chọn stop, pause và save media và resume media. + người dùng tùy chọn record ghi một file memo mới:  Hiển thị giao diện media với chức năng ghi memo.  Người dùng ấn nút start để bắt đầu ghi.  Ghi xong thì người dùng chọn nút save để lưu lại. 93 Alternative Flow Exit option -Người dùng ấn nút stop. -Và chuyển sang giao diện chức năng khác. Special Requirements Pre Requirements Người dùng đang ở menu chính của hệ thống. Post Condition Nghe media hoặc ghi media. 94 Tài liệu tham khảo [1] Ramnivas Laddad, AspectJ in Action. [2] Siobhán Clarke, Elisa Baniassad, Aspect-Oriented Analysis and Design: The Theme Approach. [3]