3.2.1 Các chức năng hệ thống
Từ phát biểu của bài toàn ở trên, chúng tôi xây dựng hệ thống xử lý hoá đơn sẽ có
các chức năng cụ thể sau đây:
1. Tạo và chỉnh sửa một khách hàng.
2. Tạo và chỉnh sửa một hàng hóa.
4. Tạo một dòng mới của hóa đơn.
Các yêu cầu phi hình thức của hệ thống
(R1) - Một sản phẩm đã bán hết thì không được xuất bán trong hóa đơn.
(R2) - Nếu có sự thay thế cho một sản phẩm đã bán hết, hệ thống phải thay thế
trong hóa đơn sản phẩm được yêu cầu bằng sản phẩm mà có thể thay thế nó.
(R3) - Không có hai dòng trên cùng một hoá đơn của cùng một sản phẩm.
(R4) - Không được xuất hoá đơn cho khách hàng không khai báo trước.
(R5) - Tổng số tiền giảm giá của một hoá đơn không được lớn hơn giá trị lớn
nhất cho phép.
(R6) – Khách hàng thân thiết giảm giá 20%, các khách hàng khác không được
giảm giá.
Xử lý lỗi
Hệ thống có thể thông báo cáo lỗi khi nhập vào một sản phẩm mới trong hóa đơn
trong trường hợp:
(1) Sản phẩm đã đã được bán hết và không có sản phẩm thay thế tương ứng
(xem (R1) và (R2)).
(2) Sản phẩm, hoặc thay thế của nó đã có trong hóa đơn thì sẽ không có thêm
dòng nữa được nhập vào hóa đơn ((R2) và (R3)).
(3) Số tiền giảm trừ của hóa đơn vượt quá giá trị cho phép khi đưa thêm các
hàng hóa hoặc sản phẩm thay thế mới vào ((R2), (R5) và (R6)).
Mô hình thành phần
3.2.2 Thành phần Client (Khách hàng)
Theo mô hình thành phần ở trên (Hình 3), chúng ta thấy rằng thành phần Client
(khách hàng) là thành phần thụ động, vì vậy có dạng
, , , ,
Client= Ctr Dep SDep Mcode SInv , cụ thể:
• Hợp đồng Ctr= Fd Md, ,Rd Mspec Init Inv, , , .
• Tập Dep chứa các tên của thành phần, mỗi phần tử trong Dep là tên của thành phần mà Client phụ thuộc vào.
• SDep là tập các biến trong Π (biểu thị sự tương tác với lịch trình).
• SInv là một vị từ trên các biến v∈SDep.
• Mcode gán cho mỗi phương thức op trong Md một thiết kế xây dựng từ các hoạt động cơ bản và phương thức gọi có mẫu call Comp C op( , , 1), trong đó
1
op là một phương thức trong thành phần C nằm trong Dep.
• Rd – một khai báo tài nguyên, đó là một tập con của RES
• Init là một giá trị khởi tạo, đó là sự kết hợp mỗi biến trong Fd và biến địa phương có giá trị cùng loại, một biến trong Rd với một số nguyên
• Mspec là đặc tả của một phương thức được kết hợp giữa phương thức op(in, out) trong Md với một thiết kế có tính tới yếu tố thời gian α,FP FR, , trong đó (α \(in∪out))⊆Fd
• Inv là một vị từ về các thuộc tính trong hợp đồng (được gọi là tính bất biến của hợp đồng).
Mô tả chi tiết các thuộc tính của thành phần Client
Tập Dep = {Invoice, Invoice_System} chứa tên 2 thành phần là Invoice và
Invoice_System mà Client phụ thuộc vào.
Rd - Sử dụng 2 tập
(1) Tập CLIENT là một bộ tập biểu thị tất cả các khách hàng có thể (hiện tại và
tương lai).
(2) Tập CATEGORY là viết tắt của các loại khác nhau của khách hàng.
C ATEGORY = {friend, dubious, normal}
Md - Tập hợp các phương thức của thành phần Client
{discount(), create_client(a), read_client(), modify_category(c,k), modify_allowance(c,a)}
Tập Fd chứa các biến của thành phần là
Vị từ Inv về các thuộc tính trong hợp đồng
client ⊆ C LI ENT ∧
category ∈ client → C ATEGORY ∧ allowance ∈ client → NAT
Giá trị khởi tạo Init
client, category, allowance := ∅, ∅, ∅
Tính tỷ lệ giảm giá Discount
Hàm discount là một chức năng liên kết từng loại khách hàng với tỷ lệ giảm giá
tương ứng sẽ được áp dụng cho tổng hoá đơn của họ.
c ← discount() =ˆ discount ∈ CATEGORY → (0..100) ∧
discount = {friend → 80, dubious → 100, normal → 100}
Chức năng create_client
Chức năng tạo mới khách hàng create_client() có biết đầu vào a : NAT đại diện
cho các mức giảm giá của khách hàng đăng ký mới. Khách mới được gán hạng mặc
định là normal.
c ← create_client(a) =ˆ
Với tiền điều kiện
a ∈ NAT ∧ client ≠ CLIENT
Thì
Với ∀ cc sao cho cc ∈ CLIENT − client
Thì ta có
client := client ∪{cc}║category(cc) := normal║ allowance(cc) := a║c := cc
Các chức năng khác
c ← read_client =ˆ
Với tiền điều kiện
client = ∅
Thì
c :∈ client modify_category(c,k) =ˆ
Với tiền điều kiện
c ∈ client ∧
k ∈ CATEGORY
Thì
modify_allowance(c,a) =ˆ …
3.2.3 Thành phần Product (Sản phẩm)
Thành phần Product được dùng để thể hiện các sản phẩm, sau đây là chi tiết các
thuộc tính của Product.
Tập Dep = {Invoice, Invoice_System} chứa tên 2 thành phần là Invoice và
Invoice_System mà Product phụ thuộc vào.
Rd - Sử dụng 2 tập
(1) Tập PRODUCT là một tập biểu thị tất cả các sản phẩm có thể (hiện tại và
tương lai).
(2) Tập STATUS là tập chứa tình trạng của sản phẩm.
STATUS = {available, sold_out}
Md - Tập hợp các phương thức của thành phần Product
{create_product(c), make_unavailable(p), assign_substitute(p, q), modify_price(p,c), read_product() }
Tập Fd chứa các biến của thành phần là
product, price, status, substitute
Vị từ Inv về các thuộc tính trong hợp đồng
product ⊆ PRODUCT ∧ price ∈ product → N AT ∧ status ∈ product → STATUS ∧
substitute ∈ product status−1[{available}]
Giá trị khởi tạo Init
product, price, status, substitute := ∅, ∅, ∅, ∅
Chức năng create_product
Hàm tạo một sản phẩm: Cho tham số c là thể hiện giá của sản phẩm. Trạng thái
mặc định khi tạo là trạng thái có sẵn.
p ← create product(c) =ˆ
Với tiền điều kiện
c ∈ NAT ∧ product = PRODUCT
Thì
Với ∀pp sao cho pp ∈ PRODUCT - product
Thì ta có
price(pp) := c ∥ status(pp):= available ∥
product := product ∪ {pp} ∥ p := pp
Các chức năng khác
Với tiền điều kiện p ∈ product Thì status(p) := sold_out∥ substitute := substitute ⊳{p} assign_substitute(p, q) =ˆ
Với tiền điều kiện
p ∈ product ∧ q ∈ product ∧ status(q) = available Thì substitute(p) := q modify_price(p,c) =ˆ… p ← read_product =ˆ. . .
3.2.4 Thành phần Invoice (Hóa đơn)
Thành phần Invoice được dùng để thể hiện các hóa đơn bán hàng, sau đây là chi
tiết các thuộc tính của Invoice.
Thành phần Invoice sử dụng 2 thành phần Client và Product (vì nó cần truy cập
vào một số biến của hai thành phần này).
Tập Dep = { Invoice_System} chứa tên thành phần là Invoice_System mà Invoice
phụ thuộc vào.
Rd - Sử dụng 2 tập
(1) Tập INVOICE là một tập biểu thị tất cả các hóa đơn có thể (hiện tại và tương lai).
(2) Tập LINE là một tập biểu thị tất cả các dòng có thể.
Md - Tập hợp các phương thức của thành phần Invoice
{ create_invoice_header(c), new_line(i, p), the_line(i,p), increment(l, q), remove_all_lines(i), remove_invoice_header(i) }
Tập Fd chứa các biến của thành phần là
invoice, customer, percentage, allowed, total, line, origin, article, quantity, unit_cost
Vị từ Inv về các thuộc tính trong hợp đồng
invoice ⊆ INVOICE ∧ customer ∈ invoice → client ∧
percentage ∈ invoice → (0..100) ∧ allowed ∈ invoice → N AT ∧ total ∈ invoice → N AT ∧ ran(total ⊗ allowed) ⊆ leq ∧
line ⊆ LINE ∧ origin ∈ line → invoice ∧ article ∈ line → product ∧ quantity ∈ line → NAT ∧ unit_cost ∈ line → NAT ∧
origin ⊗ article ∈ line ⊳ invoice × product
Tạo một hóa đơn (Invoice)
Chức năng này được thiết kế để tạo một hóa đơn cho một khách hàng hợp lệ (R4).
inv ← create_invoice_header(c) =ˆ
Với tiền điều kiện
c ∈ client ∧ category(c) = dubious ∧ invoice = I NVOICE ∧ 0 < ≤ 300
Thì
Với ∀ j sao cho j ∈ INVOICE − invoice
Thì ta có
invoice := invoice ∪ {j }∥customer(j ) := c ∥ percentage(j ) := discount(category(c))∥
allowed(j ) := allowance(c) ∥ inv := j
Thêm một dòng vào hoán đơn
Chức năng này làm nhiệm vụ thêm 1 dòng vào hóa đơn khi sản đó chưa có trên
hóa đơn.
l ← new_line(i, p) =ˆ
Với tiền điều kiện
i ∈ invoice ∧ p ∈ product ∧ status(p) = available ∧ (i, p) ∉ ran(origin ⊗ article) ∧ line = LI N E
Thì
Với ∀m sao cho m ∈ LI N E − line
Thì ta có
l := m ∥ line := line ∪ {m}∥ origin(m) := i ∥ article(m) := p ∥
quantity(m) := 0 ∥ unit_cost(m) := price(p)
Lấy một dòng
Chức năng này là để lấy 1 dòng của một sản phẩm đã có sẵn mà nó đã xuất hiện tại
một dòng nào đó của hóa đơn.
l ← the_line(i,p) =ˆ
Với tiền điều kiện
i ∈ invoice ∧ p ∈ product ∧
status(p) = available ∧ (i,p) ∈ ran(origin ⊗ article)
42
l := (origin ⊗ article)-1 (i, p)
Tăng thêm trên 1 dòng
Chức năng này thực hiện nhiệm vụ tăng số lượng của sản phẩm trên một dòng, nó
tương ứng với trường hợp sản đã có dòng chứa sản phẩm đó trong hóa đơn. Trong trường hợp này thông tin về số lượng sẽ tăng lên tương ứng.
increment(l, q) =ˆ
Với tiền điều kiện
l ∈ line ∧ q ∈ NAT ∧
status(article(l)) = available ∧ quantity(l) + q ∈ N AT ∧
total(origin(l)) + (q × unit_cost(l) × percentage(origin(l))/100) ≤ allowed(origin(l)))
Thì
quantity(l) := quantity(l) + q ∥
total(origin(l)) := total(origin(l))+
(q × unit_cost(l) × percentage(origin(l))/100)
Xóa tất cả các dòng trên hóa đơn
remove_all_lines(i) =ˆ
Với tiền điều kiện
i ∈ invoice
Thì
line := line - origin-1[{i}] ∥
origin := (origin-1 [{i}] ⊲ origin) ∥
article := (origin-1 [{i}] ⊲ article) ∥
quantity := (origin-1 [{i}] ⊲ quantity) ∥
unit_cost := (origin-1 [{i}] ⊲ unit_cost)
Trong đó với hàm f và tập Sta định nghĩa
dom(S ⊲ f ) =ˆ dom(f ) – S
(S ⊲ f )(x) =ˆ f (x)
Xóa một hóa đơn
Chức năng remove_invoice_header() được dung để xóa phần header của một hoán
đơn.
remove_invoice_header(i) =ˆ
Với tiền điều kiện
i ∈ invoice ∧ i ∉ ran(origin)
Thì
customer := {i} ⊲ customer ∥
percentage := {i}⊲ percentage ∥
allowed := {i}⊲ allowed ∥
total := {i}⊲ total
Hóa đơn có thể bị xóa sau khi xóa tất cả các dòng bằng chức năng
remove_all_lines(), tức là i ∉ ran(origin).
3.2.5 Thành phần hệ thống xuất hoá đơn (Invoice_System)
Thành phần Invoice_System làm nhiệm vụ kết nối tất cả các thành phần khác.
Chúng tôi thêm một số chức năng để giúp trong việc xác định báo cáo lỗi tốt hơn. Sau
đây là chi tiết các thuộc tính của Invoice_System:
Thành phần Invoice_System sử dụng đến các chức năng của 3 thành phần Client,
Product và Invoice.
Tập Dep = ∅.
Md - Tập hợp các phương thức của thành phần Invoice_System
{ some_client_exists, clients_not_saturated, client_not_dubious(c), some_product_exists, products_not_saturated, product_avaliable(p), product_has_substitute(p), invoices_not_saturated, new_product_in_invoice(i,p)} Trong đó: b ← some_client_exists =ˆ … ; b ← clients_not_saturated =ˆ … ; b ← client_not_dubious(c) =ˆ … ; b ← some_product_exists =ˆ … ; b ← products_not_saturated =ˆ … ; b ← product_avaliable(p) =ˆ … ; b ← product_has_substitute(p) =ˆ … ; b ← invoices_not_saturated =ˆ … ; b ← new_product_in_invoice(i; p) =ˆ … ; 3.3 Nhận xét về ví dụ
Trong chương này đã minh họa một ví dụ là xây dựng hệ thống xuất hóa đơn bán
hàng nhằm làm rõ các nội dung của lý luận cho mô hình phát triển hướng thành phần
do chúng tôi đề xuất ở Chương 2. Tuy nhiên các minh họa và mô tả còn nhiều điểm
phải dùng ngôn ngữ tự nhiên để mô tả do trong phạm vi của luận văn này chúng tôi
chưa đưa ra được một ngôn ngữ cụ thể cho mô hình của chúng tôi. Công việc xây
dựng và đề xuất một bộ ngôn ngữ cho mô hình do chúng tôi đề xuất sẽ được thực hiện
KẾT LUẬN
Luận văn này cố gắng đóng góp một phần rất nhỏ vào việc hoàn chỉnh phương pháp luận cho kỹ thuật phát triển phần mềm hướng thành phần. Trong phần đầu của luận văn này đã tập trung vào xem xét nghiên cứu về phương pháp luận và kiến trúc của mô hình phát triển phần mềm hướng thành phần do rất nhiều tác giả đề xuất.
Trong phần tiếp theo của luận văn đã đưa ra một mô hình của các giao diện các thành phần cho các hệ thống hướng thành phần thời gian thực. Trong đó mở rộng đặc tả của phương thức với ràng buộc thời gian, đó là mối quan hệ giữa sự nguyên sẵn có và lượng thời gian dành để thực hiện phương thức. Mô hình này hỗ trợ các đặc tả và
làm mịn của các thành phần và kiểm chứng các thuộc tính thời gian thực. Trong luận
văn chúng tôi cũng đưa ra một minh họa là xây dựng hệ thống xuất hóa đơn cho khách hàng nhằm minh họa cho mô hình và phương pháp luận đề xuất.
Từ việc nghiên cứu các phương pháp luận về việc phát triển phần mềm hướng thành phần, luận văn này đã đưa ra được một số điểm thống nhất và khác biệt giữa các lý thuyết đồng thời rút ra các khái niệm chung được nhiều lý thuyết thừa nhận. Từ mở rộng đề xuất mô hình giao diện cho các thành phần của hệ thống thành phần hướng thời gian, hy vọng sẽ đóng góp một phần vào việc chuẩn hóa phương pháp luận phát triển cho các hệ thống thời gian thực.
Hiện vẫn còn rất nhiều việc để làm cho mô hình đề xuất được chi tiết hơn như: phần đề xuất ngôn ngữ tương ứng với mô hình chưa được đề cập đến; các kỹ thuật
phân tích và xác minh cụ thể chưa được đề cập đến, hiện mới có một cách cho việc xác
minh bằng cách chứng minh định lý như PVS. Trong các nghiên cứu tiếp theo sẽ tập trung đề xuất mô hình đầy đủ hơn và tập trung giải quyết các các vấn đề thiếu sót đề cập ở trên.
TÀI LIỆU THAM KHẢO
Tài liệu tiếng Anh:
1. R. Allen (1997), A Formal Approach to Software Architecture, PhD thesis, Carnegie
Mellon, School of Computer Science.
2. R. Allen and D Garlan (1997), “A formal basis for architectural connection”, ACM
Transactions on Software Engineering and Methodology, 6(3), pp. 213 – 249.
3. F. Arbab (2004), “Reo: A channeled based coordination model for components
composition”, Mathematical Structures in Computer Science, 14(3), pp. 329–366.
4. L. Bass, P. Clements, and R. Kazman (1999), Software Architecture in Practice,
Addison-Wesley.
5. G. Beneken and U. Hammerschall et al (2003), “Componentware - Sate of the art
2003”, Background Paper for Understanding Components Workshop of the CUE
Initiative.
6. M. Broy (2003), Multi-view modeling of software systems, Report No.284, UNU-
IIST, P.O.Box 3058, Macau.
7. M. Broy and K. Stølen (2001), Specification and Development of Interactive
Systems: FOCUS on Streams, Interfaces, and Refinement, Springer.
8. Zhou Chaochen, Anders P. Ravn, and Michael R.Hansen (1993), “An Extended
Duration Calculus for Real-time Systems”, Hybrid Systems, LNCS 736.
9. M.R.V. Chaudron and E. de Jong (2000), “Components are from Mars”, Proc. 15
IPDPS 2000 Workshops on Parallel and Distributed Processing, LNCS 1800, pp. 727 – 733.
10. Xin Chen, He Jifeng, Zhiming Liu and Naijun Zhan (2006), A Model of
Component-Based Programming, Report No.350, UNU-IIST, P.O. Box 3058, Macau.
11. Zhenbang Chen, Abdel Hakim Hannousse, Dang Van Hung et al (2007),
Modelling with Relational Calculus of Object and Component Systems - rCOS, Report No.382, UNU-IIST, P.O. Box 3058, Macau.
12. Dino Distefano, Joost-Pierter Katoen, and Arend Rensink (2000), On a Temporal
Logic for Object-based Systems, Faculty of Computer Science, University of Twente, P.O. Box 217, 7500 AE Enschede, The Netherlands.
13. Steve Dunne, Bill Stoddart (2006), Unifying Theories of Programming, First
International Symposium, UTP 2006, Springer, UK
14. Hartmut Ehrig et al (2004), Integration of Software Specification Techniques for Applications in Engineering, Priority Program SoftSpez of the German Research Foundation (DFG), LNCS 3147, Springer.
15. Stephan Flake and Wolfgang Mueller (2002), “ A UML Profile for Real-Time
Constraints with OCL”. UML 2003, LNCS 2460, Springer-Verlag.
16. Dimitar P. Guelev, Dang Van Hung (2007), Reasoning about QoS Contracts in the
17. G. Go¨ ssler and J. Sifakis (2005), “Composition for component-based modeling”,
Science of Computer Programming, 55(1-3).
18. Dieter K. Hammer (2002), Software Architectures and Component Technology
(Editor: Mehmet Aksit), chapter Component-based Architecting for Distributed Real- time Systems, Kluwer.
19. He Jifeng, Zhiming Liu, and Li Xiaoshan (2004), Contract-Oriented Development
of Component Software, Report No.298, UNU-IIST, P.O.Box 3058, Macau.
20. He Jifeng, Xiaoshan Li, and Zhiming Liu (2005), Component-Based Software
Engineering - the Need to Link Methods and their Theories, Report No.330, UNU- IIST, P.O.Box 3058, Macau.
21. J. He, Z. Liu, and X. Li (2005), rCOS: A refinement calculus for object systems,
Report No.322, UNU-IIST, P.O. Box 3058, Macau.
22. J. He, Z. Liu, and X. Li (2005), Reactive Components, Report No.327, UNU-IIST,
P.O. Box 3058, Macau.
23. J. He, Z. Liu, X. Li, and S. Qin (2004), “A relational model of object oriented
programs”, Proceedings of the Second ASIAN Symposium on Programming Languages
and Systems (APLAS04), LNCS 3302, pp. 415–436, Springer.
24. C.A.R. Hoare and He Jifeng (1998), Unifying Theories of Programming, Prentice
Hall Series in Computer Science, Prentice Hall.
25. Tony Hoare (2003), “ The verifying compiler: A grand challenge for computing
research”, Computer Science 2003, LNCS 2622, pp. 262–272, Springer-Verlag.