ĐẠI HỌC ĐÀ NẴNG
ĐẠI HỌC BÁCH KHOA
KHOA CÔNG NGHỆ THÔNG TIN

BÁO CÁO THỰC HÀNH
CÔNG NGHỆ PHẦN MỀM
GVHD : LÊ THỊ MỸ HẠNH
SVTH : NGUYỄN TRƯỜNG LƯU 09T4
PHAN QUỐC HẬU 09T4
TRẦN ĐỨC TRÌNH 09T4
NHÓM : 10A
Đà Nẵng, tháng 11 năm 2012
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY
ỄN TR
ƯỜNG LƯU
1
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
BÀI TẬP 1
Đề bài: Công ty IT quyết định sản xuất một máy tính mới để cung cấp một môi trường
mô phỏng cho các hệ thống thời gian thực. Công ty cần các công nghệ và hệ điều hành mới
để để sản xuất máy tính. Phần mềm hệ thống cung cấp giao diện giữa hệ điều hành và phần
cứng cần phải được phát triển. Công ty quyết định sử dụng ngôn ngữ lập trình Java
đ
ể viết
phần mềm hệ thống. Tuy nhiên, Java có một số hạn chế trong lập trình hệ thống. Nhóm phát
triển xác định một số tính năng mở rộng cần được tích hợp thêm vào chương tr

1. Trao đổi với khách hàng - nhiệm vụ đòi hỏi thiết lập việc trao đổi có hiệu quả giữa
người phát triển và khách hàng.
2. Lập kế hoạch - nhiệm vụ đ
òi h
ỏi định ngh
ĩa các t
ài nguyên, h
ạn thời gian và các
thông tin liên quan tới dự án.
3. Phân tích rủi ro - nhiệm vụ đ
òi h
ỏi định giá cả những rủi ro k
ĩ t
huật và quản lí
4. K
ĩ ngh
ệ - nhiệm vụ đ
òi h
ỏi xây dựng một hay nhiều biểu diễn cho ứng dụng
5. Xây dựng và đưa ra - nhiêm vụ đ
òi h
ỏi xây dựng, kiểm thử, thiết đặt và cung cấp
sự hỗ trợ cho người dùng (như tài liệu và huấn luyện)
6. Đánh giá của khánh hàng - nhiệm vụ đ
òi h
ỏi thu được phản hồi của khách hàng
dựa trên đánh giá về biểu diễn phần mềm được tạo ra trong giai đoạn k
ĩ ngh
ệ và được
SVTH : TR

ình ti
ến trình cổ điển vốn kết thúc khi phần mềm được chuyển
giao, mô hình xoắn ốc có thể được thích ứng để áp dụng trong toàn bộ cuộc đời của phần
mềm máy tính. Một cái nhìn khác có thể được xem xét bằng việc kiểm tra trục điểm vào dự
án, như được vẽ trong hình trên. Mỗi hình hộp được đặt theo trục có thể được dùng để biểu
diễn cho điểm bắt đầu cho các kiểu dự án khác nhau. "Dự án phát triển khái niệm" bắt đầu
tại cốt lõi của xoắn ốc và sẽ tiếp tục (nhiều lần lặp xuất hiện theo con đường xoắn ốc mà vốn
gắn với vùng tô đậm trung tâm) cho tới khi việc phát triển khái niệm là đầy đủ. Nếu khái
niệm này được phát triển thành một sản phẩm thực tại, thì tiến trình tiến qua hình hộp tiếp
(điểm vào dự án phát triển sản phẩm mới) và một "dự án phát triển mới" được khởi đầu.
Sản phẩm mới sẽ tiến hoá qua một số lần lặp quanh xoắn ốc, đi theo con đường vốn gắn
vùng có tô mầu sáng hơn vùng l
õi. V
ề bản chất, xoắn ốc, khi được đặc trưng theo cách này,
vẫn còn làm việc cho tới khi phần mềm được cho nghỉ. Có những lúc tiến trình này
“ngủ”, nhưng bất kì khi nào một thay đổi được khởi đầu, thì tiến trình này lại bắt đầu tại
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY
ỄN TR
ƯỜNG LƯU
3
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
điểm vào thích hợp (tức là nâng cao sản phẩm).
Mô hình xoắn ốc là cách tiếp cận thực tế cho việc phát triển cho các hệ thống và phần
mềm qui mô lớn. Bởi vì phần mềm tiến hoá khi tiến trình tiến hoá, nên người phát triển và
khách hàng hiểu rõ h

trình tự tuyến tính hoặc làm bản mẫu. Cần phải có thêm một số năm nữa trước khi tính
hiệu quả của mô hình quan trọng này có thể được xác định với sự chắc chắn hoàn toàn.
Ưu điểm:
 Mô hình xoắn ốc là một trong những mô hình linh hoạt nhất của vòng
đ
ời phát triển
phần mềm. Các giai đoạn phát triển phần mềm có thể được xác định bởi người quản
lý dự án, theo sự phức tạp của dự án.
 Dự án được giám sát một cách dễ dàng và hiệu quả. Mỗi giai đoạn là những vòng lặp
được chia ra một cách rõ ràng.
 Mô hình xoắn ốc hướng đến sự phân tích rủi ro trong từng giai đoạn phát triển
phần mềm.
 Sự thay đổi của phần mềm có thể được kiểm soát và giải quyết trong từng giai đoạn.
 Phù hợp với các dự án có nhiều thay đổi, môi trường làm việc không ổn định.
Nhược điểm:
 Chi phí áp dụng mô hình xoắn ốc thường rất cao.
 Mô hình xoắn ốc phức tạp và khó áp dụng.
 Đ
òi h
ỏi năng lực lãnh
đ
ạo của người quản lý dự án và năng lực của nhóm dự án cao.
 Sự thay đổi từ phía khách hang nên những bản mẫu thường không được sử dụng
trong sản phẩm thật.
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY

ăng trư
ởng, các thay đổi có
nguy cơ dẫn đến sự sụp đỗ toàn bộ hệ thống do kiến trúc hệ thống không rõ ràng mà
đư
ợc
thay đổi qua từng giai đoạn, mô hình xoắn ốc tập trung trước tiên vào việc nghiên cứu tính
rủi ro của từng giai đoạn phát triển. Với mỗi giai đoạn phát triển, nhiệm vụ đầu tiên của
nhóm dự án, phải xác định tính rủi ro của tính năng được tích hợp vào chương tr
ình d
ịch
Java như thế nào ? Liệu có dẫn đến hậu quả lớn đến toàn bộ hệ thống ? Từ những phân tích
rủi ro ban đầu cùng với đánh giá việc tích hợp từ những giai đoạn trước, người quản lý dự
án và nhóm phát triển dự án sẽ điều chỉnh và quyết định thích hợp.
Thứ hai, dự án sẽ được phát triển qua từng giai đoạn, với mỗi giai đoạn, nhóm dự án sẽ
tích hợp dần dần các tính năng vào chương tr
ình d
ịch Java, để thõa mãn các yêu cầu của
nhóm phát triển phần mềm ứng dụng và hệ thống. Nhóm dự án có thể sử dụng bản mẫu để
xác định rõ h
ơn các yêu c
ầu của tính năng cần thêm vào. Như vậy hệ thống sẽ được hoàn
thiện qua từng giai đoạn, cùng với phân tích rủi ro, hệ thống đảm bảo được tính kiến trúc.
Thứ ba, việc quản lý dự án sẽ dễ dàng và hiệu quả hơn, do sự phân chia rõ ràng của từng
giai đoạn phát triển hệ thống. Người quản lý sẽ nắm rõ từng giai đoạn, cũng như những thay
đổi đặc tả xuất hiện trong giai đoạn đó. Nếu thay đổi được xuất hiện, người quản lý và nhóm
dự án sẽ giải quyết được vấn đề dựa trên kiến trúc của hệ thống ở những giai đoạn trước đó.
Qua việc đánh giá rủi ro cùng với sự quản lý dễ dàng, người quản lý biết rõ cần phải quay trở
SVTH : TR
ẦN ĐỨC TR
ÌNH

ời phát triển phần mềm (Software Development Life Cycle:
SDLC) cần phải xác định dự án được tiếp tục hay buộc phải dừng lại.
“Press Cancel to Exit or OK to Continue”
Làm thế nào để hủy bỏ một dự án phần mềm sớm ? Chúng ta cần tiến hành các nghiên
cứu khả thi sớm trong dự án để xác định quy mô dự án là hoàn toàn khả thi. Trước tiên,
nhóm dự án chuẩn bị các tài liệu liên quan đến việc nghiên cứu khả thi. Các kết quả của
nghiên cứu khả thi là một đánh giá tính khả thi, mà tại đó các nhóm dự án, khách hàng và
quản lý dự án quyết định tiếp tục hoặc dừng dự án lại. Việc xem xét tính khả thi thường
được quyết định thông qua một buổi họp hoặc đôi khi chỉ dự vào sự quyết định của một cá
nhân dựa trên những tài liệu nghiên cứu khả thi. Các thông tin cần thiết hỗ trợ cho xem xét
tính khả thi có thể được đưa ra sau khi dự án hoàn thành khoảng 10-20%.
Nghiên cứu khả thi là một hoạt động thời gian-thử nhiệm (time-tested practice), nhưng
nó không được sử dụng nhiều. Một cuộc khảo sát của KPMG cho thấy rằng 84% các công ty
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY
ỄN TR
ƯỜNG LƯU
6
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
có dự án runaway (vượt ra khỏi kiểm soát) đ
ãđư
ợc đề xuất sử dụng nghiên cứu khả thi như
là một phương tiện ngăn ngừa các vấn đề trong tương lai ("Runaway Projects—Cause and
Effect," Software World, vol. 26, no. 3, 1995). Cuộc khảo sát này cho thấy rằng các công ty đ
ã
không thực hiện phân tích khả thi trong các dự án runaway của họ.

- chi phí cho tài nguyên cần cho việc xây dựng và phát triển thị trường tiềm năng
2. Khả thi về kỹ thuật: khảo cứu về chức năng, hiệu suất và ràng buộc có thể ảnh hưởng
tới khả năng đạt tới một hệ thống chấp nhận được. Nói cách khác, khả thi kỹ thuật là
xem xét khả năng kỹ thuật hiện tại có đủ đảm bảo thực hiện giải pháp công nghệ dự
định áp dụng hay không.
Khả thi kỹ thuật thường là l
ĩnh v
ực khó thâm nhập nhất tại giai đoạn phân tích.
Điều thực chất là tiến trình phân tích và xác
đ
ịnh nhu cầu cần được tiến hành song
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY
ỄN TR
ƯỜNG LƯU
7
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
song với việc xác nhận tính khả thi kỹ thuật. Các xem xét thường được gắn với tính
khả thi kỹ thuật bao gồm:
- Rủi ro xây dựng: liệu các phần tử hệ thống có thể được thiết kế sao cho đạt được
chức năng và hiệu suất cần thiết thỏa mãn những ràng buộc trong khi phân tích
không?
- Có sẵn tài nguyên: có sẵn các nhân viên cho việc xây dựng phần tử hệ thống đang
xét không? Các tài nguyên cần thiết khác (phần cứng và phần mềm) có sẵn cho
việc xây dựng hệ thống không ?
- Công nghệ: công nghệ liên quan đ

- Chi tiết kế hoạch phát triển phần mềm
Các tài liệu chỉ ra một hoặc một số mối nguy hiểm đối với dự án. Yêu cầu không rõ ràng,
thiếu nguồn tài trợ, lập kế hoạch không phù hợp là những nguyên nhân chính dẫn đến sự
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY
ỄN TR
ƯỜNG LƯU
8
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
thất bại của dự án được chỉ ra bởi khảo sát của Standish Group.
Nếu nhóm dự án không chuẩn bị đầy đủ các tài liệu này cho nghiên cứu khả thi, thì không
nên tổ chức cuộc họp đánh giá vì bạn không có đủ thông tin để xác định tính khả thi của dự
án.
Thời gian cần thiết để hoàn thành các tài liệu nghiên cứu khả thi phụ thuộc chủ yếu vào
bao nhiêu công việc là cần thiết để xác định các yêu cầu của phần mềm. Nếu người dùng biết
chính xác họ cần những gì ở phần mềm, giai đoạn này có thể chỉ tốn 10% tổng thời gian của
lịch trình phát triển phần mềm. Trong nhiều trường hợp điển hình khác, quá trình này có thể
mất từ 10-20%. Một số trường hợp khác, khách hàng thậm chí không biết cái học muốn là gì,
như vậy nhóm dự án phải giúp người dùng tìm ra những gì họ muốn, và như vậy thời gian bỏ
ra có thể lên đến 25% hoặc nhiều hơn.
Việc xem xét tính khả thi nên tập trung vào các câu hỏi sau:
- Khái niệm sản phẩm là khả thi ?
- Liệu có sản xuất được một sản phẩm như tầm nhìn ban đầu ?
- Ước tính chi phí hiện tại và chi phí mục tiêu để hoàn thành sản phẩm ?
- Chi phí ban đầu, chi phí mục tiêu đặt ra và chi phí hiện tại chênh lệch như thế nào?
- Chiến lược kinh doanh của phần mềm là hợp lí khi kinh phí hiện tại và dự toán kế

xác hơn mức trung bình. Đầu tiên quản lý dự án yêu cầu tài trợ cho hoạt động nghiên cứu
khả thi, tức là 10-20% đầu tiên của dự án được hoàn thành. Sau khi các tài liệu nghiên cứu
khả thi được xem xét và những người tài trợ cho dự án đưa ra quyết định “go”, người quản
lý dự án yêu cầu kinh phí tài trợ cho các phần còn lại của sản phẩm. Tại thời điểm này, vẫn
có thể xảy ra những sự thay đổi về chi phí dự án, nhưng công việc thăm d
ò s
ẽ giảm khả năng
biến đổi này.
Cuối cùng, sự yêu cầu người quản lý dự án hoàn thành 10-20% của một dự án trước khi
yêu cầu tài trợ cho phần còn lại của dự án, điều này buộc nhóm dự án phải làm việc một cách
nghiêm túc và tập trung vào những công việc ban đầu đảm bảo sự thành công của dự án.
Những hoạt động này thường được làm qua loa hoặc bỏ qua, và những hậu quả tai hại sẽ trở
nên rõ ràng vào các giai
đo
ạn cuối của dự án. Nếu đội dự án được yêu cầu hoàn thành các
công việc ban đầu quan trọng trước khi tiếp tục dự án, thì rủi ro tổng thể có thể được giảm
một cách đáng kể.
BÀI TẬP 3
Đề bài:
Câu 3.1 Hãy đặc tả bởi điều kiện trước và sau các hàm:
a. Sắp xếp một danh sách các số nguyên.
b. Đảo ngược các phần tử của một danh sách
c.Đếm số phần tử có giá trị e trong một danh sách các số nguyên
Câu 3.2 Hãy đặc tả các kiểu trừu tượng:
a. Đặc tả kiểu trừu tượng cây nhị phân
b. Đặc tả kiểu trừu tượng tập hợp
Câu 3.3 Hãy sử dụng ngôn ngữ Z đặc tả một số hệ thống quản lý:
a. Quản lý thông tin đo
àn viên đơn gi
ản có một số tính năng như: thêm, xóa, chỉnh

Pre_condition:
∀i,1<=i<=size, a[i] K
Post_condition:
∀i,1<=i<=size,b[i]=a[size+1-i].
c. Đếm số phần tử có giá trị e trong một danh sách các số nguyên
Funtion_Count ( a : danh sách số nguyên
size : số phần tử của danh sách a
e : giá trị để so sánh
result: dem : là một số nguyên
)
Pre_condition:
dem = 0
Post_condition:
∀i,1<=i<=size,a[i]=e=>dem=dem+1
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY
ỄN TR
ƯỜNG LƯU
11
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
Câu 3.2 Hãy đặc tả các kiểu trừu tượng:
a.Đặc tả kiểu trừu tượng cây nhị phân
Sort BinTree(T)
Import : T, Boolean
Operation
init : →Bintree(T)

BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
searchNode(deleteNode(L,O)) = false
With: O: T; L,R: BinTree(T)
b. Đặc tả kiểu trừu tượng tập hợp
Sort Set(T)
Import: T, Integer , Boolean
Operations
init : →Set(T)
isEmpty : Set(T) →Boolean
insert : Set(T) x T →Set(T)
delete : Set(T) x T →Set(T)
in : Set(T) x T →Boolean
union : Set(T) x Set(T) →Set(T)
intersection : Set(T) x Set(T) →Set(T)
count : Set(T) →Integer
Axioms
isEmpty (init) = true
count(init) = 0
isEmpty (insert(init,e)) = false
isEmpty (delete(insert(init,e),e)) = true
in(insert(S,e),e) = true
count (insert(S,e) ) = if in(S,e) count(S)
else count(S)+1
in(delete(S,e),e) = false
count(delete(S,e)) = if in(S,e) count(S)-1
else count(S)
in(union(S1,S2),e) = in(S1,e) ∨in(S2,e)
In(intersection(S1,S2),e) = in(S1,e) ∧in(S2,e)
With:
S,S1,S2: Set(T); e: T

Age? : AgeOfUnion
Name?
∉ dom(
Ubook)
Ubook′ = Ubook ⋃ {Name?
↦
Age?}
- Trường hợp Add thành công
AddReply == OK|ERROR
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY
ỄN TR
ƯỜNG LƯU
14
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
SuccessAdd
Reply! : AddReply
Reply! = OK
- Trường hợp Add lỗi
BadAdd
Ξ UnionBook
Name? : UnionMember
Age? : AgeOfUnion
Reply! : AddReply
Name? ∈dom(Ubook)
Reply! = ERROR

Reply! : RemoveReply
Name?
∉
dom(Ubook)
Reply! = ERROR
 khiđó:ResultRemove==(Remove∧SuccessRemove) ∨BadRemove
 Mở rộng: Xóa các đoàn viên ứng với 1 tập tên
RemoveNames
Δ UnionMember
Name? :ℙ UnionMember
Ubook′ = Name?
⩤
Ubook
+ Chỉnh sửa tuổi đoàn
Update
Δ UnionBook
Name? : UnionMember
Age? : AgeOfUnion
Name? ∈dom(Ubook)
Ubook′ = Ubook ⊕ {Name?
↦
Age?}
- Trường hợp chỉnh sửa thành công
UpdateReply == OK|ERROR
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY

ÌNH
– PHAN QU
ỐC HẬU
– NGUY
ỄN TR
ƯỜNG LƯU
17
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
SuccessLookupAge
Reply! : LookupAgeReply
Reply! = OK
. Trường hợp tìm lỗi
BadLookupAge
Ξ UnionBook
Name? : UnionMember
Age? : AgeOfUnion
Reply! : LookupAgeReply
Name?
∉
dom(Ubook)
Reply! = ERROR
 Khi đó: ResultLookupAge == (LookupAge ∧SuccessLookupAge)∨BadLookupAge
- Tìm những đoàn viên có cùng tuổi đoàn
LookupNames
Ξ UnionBook
Age? : AgeOfUnion
Name! :
ℙ
UnionMember
Name! : {p : UnionMember | p ∈dom(Ubook) ∧Ubook(p) = Age?}

⟦ Readers, IdReaders ⟧
+ Đặc tả trạng thái hệ thống
ReadersList
RList : Readers ⇸ IdReaders
+ Khởi tạo hệ thống
InitList1
ReadersList
RList = {}
+ Thêm độc giả
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY
ỄN TR
ƯỜNG LƯU
19
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
AddReader
ΔReadersList
Name? : Readers
Id1? : IdReaders
Name?
∉
dom(RList)
RList′ = RList ⋃ {Name?
↦
Id1?}
+ Xóa độc giả

– NGUY
ỄN TR
ƯỜNG LƯU
20
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
+Khởi tạo hệ thống
InitList2
BooksList
BList = {}
+ Thêm một cuốn sách
AddBook
ΔBooksList
Title? : Books
Id2? : IdBooks
Title?
∉
dom(BList)
BList′ = BList ⋃ {Title?
↦
Id2?}
+Xóa một cuốn sách
RemoveBook
ΔBooksList
Title? : Books
Id2? : IdBooks
Title? ∈dom(BList)
BList′ = BList ⧹ {Title?
↦
Id2?}
+ Sửa Id một quyển sách

Lib : IdReaders ↦ IdBooks
Number
Nb : IdReaders ⇸ Count
+ Khởi tạo hệ thống
InitLibrary
Library
Lib = {}
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY
ỄN TR
ƯỜNG LƯU
22
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
InitNumber
Number
Nb = {}
+ Mượn sách
- Mượn sách lần đầu
Borrow1
ΔLibrary
ΔNumber
Id1? : IdReaders
Id2? : IdBooks
Dem? : Count
Dem? = 0
Dem?

– NGUY
ỄN TR
ƯỜNG LƯU
23
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
SuccessBorrow
Repy! : BorrowReply
Reply! = OK
- Trường hợp mượn lỗi
BadBorrow
ΞLibrary
ΞNumber
Dem? : Count
Reply! : BorrowReply
Dem? = 5
Reply! = ERROR
 Khi đó :
ResultBorrow == ((Borrow1 ∨Borrow2)∧SuccessBorrow)∨BadBorrow
+ Trả sách
Pay1
ΔLibrary
ΔNumber
Id1? : IdReaders
Id2? : IdBooks
Dem? : Count
Dem? > 1
Dem?
′ =
Dem? – 1
Lib′ = Lib ⧹ { Id1?

Dem?}
+ Trường hợp trả thành công
PayReply == OK| ERROR
SuccessPay
Reply! : PayReply
Reply! = OK
+ Trường hợp trả lỗi
BadPay
ΞLibrary
ΞNumber
Id1? : IdReaders
Id2? : IdBooks
Dem? : Count
Reply! : PayReply
Id1?
∉
dom(Lib)
⋃
Id2?
∉ ran(
Lib) ⋃ Dem? = 0
Reply! = ERROR
 Khi đó : ResultPay == ((Pay1 ∨Pay2)∧SuccessPay)∨BadPay