Xây dựng chương trình

Một phần của tài liệu (Luận văn thạc sĩ) mô hình hóa giao diện của các thành phần trong các hệ thống dựa trên thành phần (Trang 35)

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)).

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 vSDep.

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 đó (α \(inout))⊆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

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

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_SystemInvoice

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,

ProductInvoice.

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.

Một phần của tài liệu (Luận văn thạc sĩ) mô hình hóa giao diện của các thành phần trong các hệ thống dựa trên thành phần (Trang 35)