Khái quát hệ thống và mô tả vấn đề giúp cung cấp ngữ cảnh ban đầu, phân tích các yêu cầu và thiết kế hệ thống là điều khiển các ca sử dụng. Một ca sử dụng miêu tả hệ thống tương tác như thế nào với các tác nhân và môi trường của nó trong sự thực hiện một tiến trình thương mại. Một tác nhân, như Cashier, kiểm tra khách hàng, tương tác với hệ thống bằng lời gọi một thao tác hệ thống để yêu cầu một dịch vụ của hệ thống.
Ca sử dụng UC1: Process Sale. Diễn biến thông thường của các tương tác giữa các tác nhân và hệ thống được miêu tả không hình thức như dưới đây:
1. Khi một khách hàng tới bàn thanh toán với các đồ mua, Cashier khởi tạo một sự bán hàng mới.
2. Cashier nhập mỗi mặt hàng bằng bàn phím hoặc bằng máy quét mã vạch, nếu có nhiều hơn một mặt hàng giống nhau, Cashier có thể nhập
số lượng mặt hàng. Hệ thống ghi mỗi mặt hàng và số lượng của nó để tính tổng theo loại. Khi bàn thanh toán hoạt động trong chế độ thanh toán nhanh bằng tiền mặt (express mode), chỉ có số lượng lớn nhất (được định nghĩa trước) các mặt hàng có thể được nhập vào.
3. Khi không có thêm mặt hàng nào, Cashier báo tín hiệu cho hệ thống biết là kết thúc việc nhập (end of entry). Toàn bộ việc bán hàng sẽ
được tính toán, Cashier nói cho khách hàng biết tổng tiền và yêu cầu khách hàng trả tiền.
4. Khách hàng có thể trả bằng tiền mặt hoặc bằng thẻ tín dụng. Nếu bằng tiền mặt, lượng tiền nhận sẽ được nhập, hệ thống ghi lại số lượng tiền trả và tính toán sự chênh lệch. Nếu bằng thẻ tín dụng, thông tin của thẻ được nhập vào, hệ thống đưa việc trả tiền của thẻ tới Bank để xác nhận. Việc trả tiền chỉ thành công nếu việc phản hồi sự thẩm định là đúng. Trong chế độ đặc biệt, chỉ cho phép trả bằng tiền mặt. Sau khi trả tiền, sự kiểm kê của kho được cập nhật và việc bán hàng được ghi vào nhật ký.
Có các thực hiện ngoại lệ hoặc thay thế của các tương tác, ví dụ nhập mã vạch không biết trong hệ thống, khách hàng không có đủ tiền trả cho việc trả tiền mặt, hoặc xác nhận phản hồi là không đúng. Một hệ thống cần cung cấp điều kiện chấp nhận những trường hợp ngoại lệ này, như là hủy việc bán hoặc thay đổi cách trả tiền. Khi ở mức xác định các yêu cầu, chúng ta nắm bắt các điều kiện ngoại lệ này như là các tiền điều kiện.
Mô hình hình thức của UC1: Mỗi ca sử dụng được mô hình hóa bởi hợp
đồng của giao diện cung cấp của một thành phần, gọi là thành phần ProcessSale. Gọi CASHDESKIF là giao diện cung cấp của thành phần này. Chúng ta dùng một lược đồ đặc tả thành phần và các giao diện của nó.
Một thành phần có thể có một số các giao diện cung cấp, sự kết hợp của chúng xác định giao diện cung cấp toàn thể của thành phần.
Một thành phần có thể có một số (có thể không có) các giao diện yêu cầu, sự kết hợp của chúng xác định giao diện yêu cầu toàn thể của thành phần. Mỗi giao diện chỉ khai báo các phương thức của nó, và các trường của nó
được khai báo như các thuộc tính của một lớp, được gọi là lớp giao diện, đó là công cụ thực thi giao diện.
Khi hợp đồng của giao diện được đặc tả:
Giao thức là một biểu đồ tuần tự của các tương tác giữa các tác nhân và các trường hợp của lớp thực hiện giao diện đó.
Chức năng của các phương thức giao diện được cho như các điều kiện trước và điều kiện sau của “các định nghĩa” các phương thức trong lớp thực thi giao diện.
Chúng ta yêu cầu trong khi hệ thống thực thi chỉ có một trường hợp của lớp giao diện cho mỗi thành phần. Với lược đồ này, dựa trên sự giới thiệu về hệ thống và sự miêu tả ca sử dụng, thành phần và giao diện của nó được khai báo là:
component ProcessSale {
provided interface CashDeskIF { public enableExpress();
public disableExpress(); public startSale ();
public enterItem(Barcode code, int qty); public finishSale ();
public cashPay(double a ; double c); public cardPay(Card c);}}
Các phương thức của giao diện được đặc tả như sau:
class CashDeskimplementsCashDeskIF::
invariant store null store.catalog null
(exmode = true exmode = false)
method enableExpress()
pre:true
post:exmode’ = true
method disableExpress()
pre:true
post:exmode’ = false
method startSale()
pre:true
//việc bán hàng được phát sinh
post:sale' = Sale.New(false/complete, empty/lines, clock.date()/date)
method enterItem(Barcode code, int qty) // nhập số lượng
pre:store.catalog.find(c) null
post:LineItem line' = LineItem.New(c/barcode,qty/quantity)
; line.subtotal' = store.catalog.find(c).price x qty
; sale.lines.add(line) //; thể hiện việc thực hiện tuần tự các thao tác
method finishSale()
pre:true
post:sale.complete' = true sale.total’=sum[[l.subtotal | lsale.lines]]
method cashPay(double a ; double c)
pre:a sale.total
post:sale.pay' = CashPayment.New(a/amount,a-sale.total/change)
c’= a - sale.total; store.sales.add(sale)
method cardPay(Card c)
pre:Bank.authorize(c,sale.total)
post:sale.pay' = CardPayment.New(c/card) ; store.sales.add(sale)
Làm mịn ca sử dụng UC1. Chúng ta có thể tách ca sử dụng UC1 thành hai
ca sử dụng, gồm UC1.1 là Make Cash Payment cung cấp giao diện CASHPAYMENTIF, và UC1.2 là Make Card Payment cung cấp giao diện CARDPAYMENTIF. Giao diện CASHPAYMENTIF cung cấp phương thức
cashPay(Sale sale, double a; double c) được đặc tả tương tự như phương thức
cashPay(double a; double c) trong hợp đồng cho CASHDESKIF. Giao diện CARDPAYMENTIF cung cấp phương thức cardPay(Sale sale, Card c) được đặc tả tương tự phương thức cardPay(Card c) trong hợp đồng cho CASHDESKIF.
Biểu đồ tuần tự ca sử dụng thông thường trong hình 4.4 được làm mịn thành biểu đồ tuần tự ca sử dụng trong hình 4.5.
Hình 4.5 Biểu đồ tuần tự được làm mịn của UC1
Chúng ta đạt được mô hình làm mịn của ca sử dụng UC1 được đặc tả theo cách sau:
component ProcessSale { component CashDeskComp {
required interface CashPaymentIF; required interface CardPaymentIF; provided interface CashDeskIF { public enableExpress();
public disableExpress(); public startSale ();
public enterItem(Barcode code, int qty); public finishSale ();
public cardPay(Card c);
public cashPay(double a; double c);
}
class CashDesk implements CashDeskIF { protected boolean exmode;
protected Store store; protected Sale sale;
}}
component CashPayment {
provided interface CashPaymentIF
{ public cashPay(Sale sale, double a; double c) } }
component CardPayment {
provided interface CardPaymentIF
{ public cardPay(Sale sale, Card c) } }}
Để làm rõ đầy đủ ý nghĩa các vấn đề thiết kế, chúng ta xem xét thêm hai ca sử dụng đơn giản mà không cần cung cấp biểu đồ tuần tự, biểu đồ trạng thái, biểu đồ lớp của chúng. Chúng ta sẽ viết trực tiếp chức năng các phương thức của các ca sử dụng này cùng với thành phần và sự khai báo giao diện tương ứng của chúng.
UC2: Order product. Ca sử dụng này bắt đầu với startOrder và một số lần
orderItem kế tiếp bởi makeOrder. Chúng ta chỉ đặc tả chức năng của các toán tử ca sử dụng, và bỏ qua sự khai báo các lớp liên quan. Chúng ta sử dụng
OrderProduct cho thành phần của ca sử dụng này, và cung cấp dịch vụ
receiveOrder(Order order) tới kho:
component OrderProduct {
provided interface OrderDeskIF {
public startOrder();
public orderItem(Barcode c, long q);
public makeOrder(Order order);
}
class OrderDesk implements OrderDeskIF {
protected Order order;
public startOrder() {
pre: true;
post: // một yêu cầu được tạo ra
order' = Order.New()
public orderItem(Barcode c, long q) {
pre: // mã sản phẩm c tồn tại trong catalog store . supplier .catalog.find(c) null;
post: // tạo một yêu cầu và đưa nó vào danh mục yêu cầu
Orderline line ' = OrderLine.New(c/identifier, q/quantity) ; order' = order. lines .add(line)
}
public makeOrder(Order order) {
pre: true;
post: store .order.add(order)
store . supplier .receiveOrder(order) }
} }
UC3: Manage inventory. Ca sử dụng này mang các sự thay đổi tới các mục
kiểm kê. Ở đây chúng ta chỉ đặc tả các thao tác để thay đổi giá cả của một mặt hàng và thêm vào một mặt hàng.
component InventoryManagement {
provided interface InventoryDeskIF {
public changePrice(Barcode code, double newPrice);
public addItem(Barcode c, long a, double p);
}
class InventoryDesk implements InventoryDeskIF {
protected Store store;
public changePrice (Barcode code, double newPrice) {
pre: store .catalog. find(code) null;
post: p catalog: ( if p.barcode = code then p.price'=newPrice)
}
public addItem(Barcode c, long a, double p) {
pre: valid (c ); // mã sản phẩm c là đúng
post: store .catalog.add(Item.New(c,a,p/barcode,amount,price))
} } }
Có thể thấy là trong một hệ thống hỗ trợ bán hàng còn có các phương thức khác nữa trong thành phần quản lý kho, bao gồm sự thay đổi về số lượng mặt hàng, thay đổi về giá cả sản phẩm, sự xóa đi một sản phẩm,…Tuy nhiên với những gì đã nói ở trên là đủ để minh họa cho sự tiếp cận mô hình, đặc tả thành phần được giới thiệu trong ví dụ này.
KẾT LUẬN
Mô hình hóa hệ thống dựa trên thành phần để trợ giúp việc thiết kế và phát triển hệ thống có độ phức tạp cao là một đề tài cấp thiết và thu hút sự quan tâm của nhiều nhà nghiên cứu công nghệ phần mềm, và điều đó được phần nào thể hiện trong nội dung luận văn này. Luận văn đã nêu và phân tích một số vấn đề của công nghệ phần mềm dựa trên thành phần như: mô hình vòng đời tiến trình dựa trên thành phần, chế tạo thành phần, kết hợp các thành phần, phân tích và thiết kế cho việc dùng lại thành phần, phân loại và tìm kiếm thành phần.
Thông qua luận văn, ta thấy từ góc nhìn của người dùng hoặc người gắn kết hệ thống thì một thành phần cung cấp một giao diện bao gồm một tập các thuộc tính, một tập các dịch vụ cung cấp và một tập các dịch vụ yêu cầu; còn từ góc nhìn của người thiết kế hệ thống thì một thành phần là tập hợp các đối tượng hợp tác với nhau để thực hiện giao tiếp. Luận văn đã cố gắng đưa ra những quan điểm để đem lại sự thống nhất về khái niệm trong lập trình dựa trên thành phần. Đồng thời, luận văn cũng đưa ra mô hình toán học cho các khái niệm giao diện, hợp đồng và thành phần, từ đó làm cơ sở nền tảng cho việc xây dựng mô hình phần mềm thành phần.
Một thành phần được xây dựng để cung cấp các dịch vụ và những dịch vụ này được đặc tả trong các điều khoản của giao diện và hợp đồng của thành phần. Và những đặc tả này được xem như các đặc tả yêu cầu của thành phần, người thiết kế thành phần phải thiết kế thành phần thỏa mãn các đặc tả yêu cầu này. Để tiếp cận việc mô hình hóa phần mềm thành phần, luận văn miêu tả một thành phần được đặc tả như thế nào ở mức giao diện, mức hợp đồng và các thành phần kết hợp như thế nào với nhau, qua đó cung cấp cách biểu diễn giao diện, hợp đồng và thành phần dưới dạng ngôn ngữ đặc tả. Luận văn cũng đã xem xét đến những vấn đề hiện đại trong mô hình thành phần như sự kế thừa, kết hợp và làm mịn thành phần. Và để làm rõ những vấn đề đã trình bày, chúng tôi đã tiến hành khảo sát một ví dụ (hệ thống hỗ trợ bán hàng trong siêu thị) cho việc mô hình thành phần, các thành phần được biểu diễn dưới dạng ngôn ngữ đặc tả; những điều đó được thể hiện qua các ca sử dụng Process Sale, Order Product và Manage Inventory.
Mặc dù còn tồn tại nhiều hạn chế, nhưng trên cơ sở nội dung luận văn với cách nhìn tương đối rõ ràng về kiến trúc dựa trên thành phần, chúng tôi hy vọng luận văn có thể tiếp tục được phát triển bằng cách mở rộng mô hình thành phần cho hệ thống thời gian thực, và tạo ra các từ khóa có thể tích hợp được với các ngôn ngữ lập trình khác nhau để chúng trở thành ngôn ngữ hỗ trợ cho việc lập trình dựa trên thành phần.
TÀI LIỆU THAM KHẢO Tiếng Việt
1. Ngô Trung Việt, Nguyễn Kim Ánh (2003). Nhập môn kỹ nghệ phần mềm. Nhà xuất bản Khoa học và kỹ thuật.
Tiếng Anh
2. C.A.R. Hoare (2001). Unified Theories of Programming. Prentice Hall 3. Roger S. Pressman (2001). Software Engineering, A Practitioner’s
Approach. 5th Edition, McGraw-Hill.
4. Zhenbang Chen, Abdel Hakim Hannousse, Dang Van Hung, Istvan Knoll, Xiaoshan Li, Zhiming Liu, Yang Liu, Qu Nan. Joseph C. Okika, Anders P. Ravn, Volker Stolz, Lu Yang, and Naijun Zhan. Modelling with Relational Calculus of Object and Component Systems - rCOS. Technical Report UNU/IIST Report No 382, UNU/IIST, P.O. Box 3058, Macao SAR China, 2007.
5. Zhenbang Chen, Zhiming Liu, Anders P. Ravn, Volker Stolz and Naijun Zhan. Refinement and Verification in Component-Based Model Driven Design. Technical Report UNU/IIST Report No 388, UNU/IIST, P.O. Box 3058, Macao SAR China, 2007.
6. Dang Van Hung and Pham Hong Thai. Towards a Template Language for Component-Based Programming. Technical Report No 354, UNU-IIST, P.O.Box 3058, Macao SAR China, April 2007.
7. Zhiming Liu, He Jifeng and Xiaoshan Li, Contract-Oriented Development of Component Software. Technical Report UNU/IIST Report No 298, UNU/IIST, P.O. Box 3058, Macao SAR China, 2004.
8. Zhiming Liu, Charles Morisset and Volker Stolz, rCOS: Theory and Tool for Component-Based Model Driven Development. Technical Report UNU/IIST Report No 406, UNU/IIST, P.O. Box 3058, Macao SAR China, 2009.
9. He Jifeng, Zhiming Liu and Li Xiaoshan. Contract-Oriented Component Software Development. Technical Report UNU/IIST Report No 276, UNU/IIST, P.O. Box 3058, Macao SAR China, 2003.
10.He Jifeng, Xiaoshan Li and Zhiming Liu. Component-based Software Enginerring, the Need to Link Methods and their Theories. Technical Report UNU/IIST Report No 330, UNU/IIST, P.O. Box 3058, Macao SAR China, 2005.
11.Kim Pyong Sam and Dang Van Hung. A UTP Approach Semantics for Component-Based Real-Time Systems. Technical Report UNU/IIST Report No 303, UNU/IIST, P.O. Box 3058, Macao SAR China, 2005.