Kiểm chứng mô hình aspect-uml bằng alloy

1
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
Bùi Duy Hải
KIỂM CHỨNG MÔ HÌNH ASPECT-UML BẰNG
ALLOY
KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY
Ngành: Công nghệ thông tin
HÀ NỘI - 2010
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
Bùi Duy Hải
KIỂM CHỨNG MÔ HÌNH ASPECT-UML BẰNG
ALLOY
KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY
Ngành: Công nghệ thông tin
Cán bộ hướng dẫn: Phạm Thị Kim Dung
HÀ NỘI - 2010
LỜI CÁM ƠN
Đầu tiên tôi xin gửi lời cảm ơn sâu sắc tới cô giáo Ths.Phạm Thị Kim Dung,
bộ môn công nghệ phần mềm, khoa công nghệ thông tin, trường đại học công nghệ,
đại học Quốc Gia Hà Nội – người đã định hướng đề tài và tận tình hướng dẫn chỉ
bảo tôi trong suốt quá trình thực hiện khóa luận tốt nghiệp này.
Tôi cũng xin trân trọng cảm ơn quý thầy cô trong Khoa Công nghệ thông tin
trường Đại học Công nghệ, Đai học Quốc Gia Hà Nội đã tận tình giảng dạy, truyền
đạt những kiến thức quý báu trong suốt bốn năm học làm nền tảng cho tôi thực hiện
khóa luận tốt nghiệp này.
Con xin cảm ơn cha mẹ và gia đình đã sinh ra và nuôi dạy con khôn lớn,
luôn bên cạnh động viên và ủng hộ con trên con đường mà con yêu thích và lựa
chọn.
Cám ơn các bạn sinh viên Khoa công nghệ thông tin khóa 2006-2010. Các

bạn đã giúp đỡ và ủng hộ tôi rất nhiều cũng như đóng góp nhiều ý kiến quý báu,
qua đó, giúp tôi hoàn thiện khóa luận tốt hơn.
Mặc dù đã rất nỗ lực, cố gắng nhưng chắc hẳn khóa luận của tôi vẫn còn
nhiều thiếu sót. Tôi rất mong nhận được nhiều những ý kiến đánh giá quý, phê bình
của quý thầy cô, của anh chị và các bạn.
Một lần nữa tôi xin chân thành cảm ơn!
Hà Nội, tháng 5 năm 2010
Bùi Duy Hải
Mục Lục
Bùi Duy Hải ........................................................................................................................................................ 1
Bùi Duy Hải ........................................................................................................................................................ 2
1 Chương 1 : MỞ ĐẦU ....................................................................................................................................... 6
1.1 Đặt vấn đề ................................................................................................................................................ 6
1.2 Cấu trúc khóa luận ................................................................................................................................... 6
2 Chương 2: Giới thiệu về mô hình UML và lập trình hướng Aspect ................................................................ 7
2.1 Mô hình UML (Unifined Model Language) .............................................................................................. 7
2.1.1 Lịch sử phát triển của UML .............................................................................................................. 7
2.1.2 Ứng dụng của mô hình UML ............................................................................................................ 9
2.1.3 Các loại biểu đồ UML ...................................................................................................................... 12
2.2 Ngôn ngữ ràng buộc đối tượng (OCL) ................................................................................................... 13
2.3 Lập trình hướng khía cạnh (Aspect Oriented Programming) ................................................................ 15
2.3.1 Phương pháp lập trình hướng khía cạnh ........................................................................................ 15
2.3.2 Các khái niệm trong Aspect ............................................................................................................ 20
3 Chương 3: Kiểm chứng mô hình Aspect-UML .............................................................................................. 23
3.1 Giới thiệu về Alloy .................................................................................................................................. 23
3.1.1 Alloy[4] là gì? ................................................................................................................................... 23
3.1.2 Tính chất của ngôn ngữ alloy .......................................................................................................... 23
3.1.3 Cấu trúc một chương trình Alloy .................................................................................................... 24
3.1.4 Khai báo trong alloy ........................................................................................................................ 24
3.2 Đặc tả mô hình Aspect-UML trong Alloy ............................................................................................... 28

3.2.1 Mô hình Aspect UML ...................................................................................................................... 28
3.2.2 Mô hình viễn thông ....................................................................................................................... 30
3.2.3 Đặc tả mô hình Aspect UML bằng Alloy ......................................................................................... 32
3.2.4 Kiểm chứng mô hình Aspect UML sử dụng Alloy ........................................................................... 37
4 Chương 4 : Kết luận ...................................................................................................................................... 40
DANH MỤC HÌNH VẼ
Figure 1.............................................................................................................................................................16
DANH MỤC BẢNG BIỂU
DANH MỤC NHỨNG TỪ VIẾT TẮT
OOP Object Oriented Programming
UML Unifined Model Language
OCL Object Contraint Language
AOP Aspect Oriented Programming

1 Chương 1 : MỞ ĐẦU
1.1 Đặt vấn đề
Ngày nay, công nghệ thông tin ngày càng phát triển và được ứng dụng vào tất cả các
lĩnh vực của cuộc sống xã hội. Nó tạo ra một diện mạo mới cho xã hội và nhờ đó nền văn
minh nhân loại được nâng lên một tầm cao mới. Công nghệ phần mềm là một phần không
thể tách rời trong công nghệ thông tin. Hiện nay ngành công nghệ phần mềm trên thế giới
đã và đang phát triển như vũ bão. Những tiến bộ của khoa học kĩ thuật phần cứng đã tạo
điều kiện thuận lợi cho công nghệ phần mềm ngày càng phát triển không ngừng.
Phần mềm được coi là sản phẩm chính của công nghệ phần mềm.Quá trình phát
triển phần mềm gồm nhiều giai đoạn: thu thập yêu cầu, phân tích, thiết kế,xây dựng, kiểm
chứng , triển khai và bảo trì. Trong đó việc kiểm chứng phần mềm là hết sức quan trọng
để đảm bảo chất lượng của một phần mềm.
Kiểm chứng mô hình UML cũng đóng góp vào việc kiểm chứng phần mềm.Việc
kiểm chứng mô hình UML + OCL đã được giải quyết [2]. Vấn đề đặt ra bây giờ là kiểm
chứng mô hình Aspect-UML(là một mô hình UML đơn giản được mở rộng với việc sử
dụng Aspect). Nhờ Aspect và các ràng buộc của nó mà mô hình Aspect UML được cung

cấp thêm thông tin. Mô hình Aspect UML có thể được kiểm chứng từ các xung đột
tương tác Aspect, để làm tự động công việc kiểm chứng mô hình Aspect UML là chuyển
đổi mô hình Aspect UML sang ngôn ngữ đặc tả Alloy. Alloy cung cấp một ngôn ngữ đặc
tả mô hình đơn giản dựa trên logic cũng như công cụ mô phỏng[]. Trong phạm vi khóa
luận này tôi sẽ chỉ ra quy tắc chuyển đổi một mô hình Aspect UML sang ngôn ngữ
Alloy.
1.2 Cấu trúc khóa luận
Chương 1: Phần mở đầu.
Chương 2: Giới thiệu về mô hình UML và lập trình hướng Aspect.
Chương 3: Kiểm chứng mô hình Aspect- UML bằng Alloy
Chương 4: Kết luận và hướng nghiên cứu trong tương lai.
2 Chương 2: Giới thiệu về mô hình UML và lập trình hướng Aspect
2.1 Mô hình UML (Unifined Model Language)
2.1.1 Lịch sử phát triển của UML
Theo [1] những năm đầu của thập kỷ 90 có rất nhiều phương pháp phân tích, thiết kế
hệ thống hướng đối tượng và cùng với chúng là các ký hiệu riêng cho từng phương
pháp. Số lượng các phương pháp trong khoảng từ 10 đã lên đến gần 50 trong những
năm từ 1989 đến 1994. Ba phương pháp phổ biến nhất là OMT (Object Modeling
Technique) [James Rumbaugh], Booch91 [Grady Booch] và OOSE (Object-Oriented
Software Enginering) [Ivar Jacobson]. Mỗi phương pháp đều có những điểm mạnh và
yếu. Như OMT mạnh trong phân tích và yếu ở khâu thiết kế, Booch91 thì mạnh ở thiết
kế và yếu ở phân tích. OOSE mạnh ở phân tích các ứng xử, đáp ứng của hệ thống mà
yếu trong các khâu khác.
Do các phương pháp chưa hoàn thiện nên người dùng rất phân vân trong việc chọn
ra một phương pháp phù hợp nhất để giải quyết bài toán của họ. Hơn nữa, việc các ký
hiệu khác nhau của các phương pháp đã gây ra những sự mập mờ, nhầm lẫn khi mà một
ký hiệu có thể mang những ý nghĩa khác nhau trong mỗi phương pháp. Ví dụ như một
hình tròn được tô đen biểu hiện một multiplicity trong OMT lại là một aggregation
trong Booch). Thời kỳ này còn được biết đến với tên gọi là cuộc chiến giữa các phương
pháp. Khoảng đầu năm 94, Booch đã cải tiến phương pháp của mình trong đó có ứng

dụng những ưu điểm của các phương pháp của Rumbaugh và Jacobson. Tương tự
Rumbaugh cũng cho đăng một loạt các bài báo được biết đến với tên gọi phương pháp
OMT-2 cũng sử dụng nhiều ưu điểm của phương pháp của Booch. Các phương pháp đã
bắt đầu hợp nhất, nhưng các kí hiệu sử dụng ở các phương pháp vẫn còn nhiều điểm
khác biệt.
Cuộc chiến này chỉ kết thúc khi có sự ra đời của UML – một ngôn ngữ mô hình hóa
hợp nhất. Tại sao lại là hợp nhất? Đó là do có sự hợp nhất các cách kí hiệu của Booch,
OMT và Objectory cũng như các ý tưởng tốt nhất của một số phương pháp khác như
hình vẽ sau:
Hình 1:Hợp nhất các phương pháp thiết kế bằng UML
Bằng cách hợp nhất các kí hiệu sử dụng trong khi phân tích, thiết kế của các phương
pháp đó, UML cung cấp một nền tảng chuẩn trong việc phân tích thiết kế. Có nghĩa là
các nhà phát triển vẫn có thể tiến hành theo phương pháp mà họ đang sử dụng hoặc là
có thể tiến hành theo một phương pháp tổng hợp hơn( do thêm vào những bước ưu
điểm của từng phương pháp). Nhưng điều quan trọng là các ký hiệu giờ đây đã thống
nhất và mỗi ký hiệu chuẩn của tổ chức OMG (Object Management Group) vào tháng
7-1997.
2.1.2 Ứng dụng của mô hình UML
UML là một ngôn ngữ dùng để:
• Trực quan hóa
• Cụ thể hóa
• Sinh mã ở dạng nguyên mẫu
• Lập và cung cấp tài liệu
UML là một ngôn ngữ bao gồm một bảng từ vựng và các quy tắc để kết hợp các từ
vựng đó phục vụ cho mục đích giao tiếp. Một ngôn ngữ dùng cho việc lập mô hình là
ngôn ngữ mà bảng từ vựng( các ký hiệu) và các quy tắc của nó tập trung vào việc thể
hiện về mặt khái niệm cũng như vật lý của một hệ thống.
Mô hình hóa mang lại sự hiểu biết về một hệ thống. Một mô hình không thể giúp
chúng ta hiểu rõ một hệ thống, thường là phải xây dựng một số mô hình xét từ những
góc độ khác nhau. Các mô hình này có quan hệ với nhau.

UML sẽ cho ta biết cách tạo ra và đọc hiểu được một mô hình đươc cấu trúc tốt,
nhưng nó không cho ta biết những mô hình nào nên tạo ra và khi nào tạo ra chúng. Đó
là nhiệm vụ của quy trình phát triển phần mềm.
2.1.2.1 UML là ngôn ngữ dùng để trực quan hóa
Đối với nhiều lập trình viên, không có khoảng cách nào giữa ý tưởng để giải quyết
một vấn đề và việc thể hiện điều đó thông qua các đoạn mã. Họ nghĩ ra và họ viết mã.
Trên thực tế, điều này gặp một số vấn đề. Thứ nhất, việc trao đổi về các ý tưởng giữa
những người lập trình sẽ gặp khó khăn, trừ khi tất cả đều nói cùng một ngôn ngữ. Thậm
chí ngay cả khi không gặp trở ngại về ngôn ngữ thì đối với từng công ty, từng nhóm
cũng có những “ngôn ngữ” riêng của họ. Điều này gây trở ngại cho một người mới vào
để có thể hiểu được những việc đang được tiến hành. Hơn nữa, trong lĩnh vực phần
mềm, nhiều khi khó có thể hiểu được nếu chỉ xem xét các đoạn mã lệnh. Ví dụ như sự
phân cấp của các lớp, ta có thể phải duyệt rất nhiều đoạn lệnh để hiểu được sự phân cấp
của các lớp. Và nếu như người lập trình không mô tả các ý tưởng mà anh ta đã xây
dựng thành mã lệnh thì nhiều khi cách tốt nhất là xây dựng lại trong trường hợp một
người khác đảm nhận tiếp nhiệm vụ khi anh ta rời khỏi nhóm
Đối với nhiều lập trình viên, không có khoảng cách nào giữa ý tưởng để giải quyết
một vấn đề và việc thể hiện điều đó thông qua các đoạn mã. Họ nghĩ ra và họ viết mã.
Trên thực tế, điều này gặp một số vấn đề. Thứ nhất, việc trao đổi về các ý tưởng giữa
những người lập trình sẽ gặp khó khăn, trừ khi tất cả đều nói cùng một ngôn ngữ. Thậm
chí ngay cả khi không gặp trở ngại về ngôn ngữ thì đối với từng công ty, từng nhóm
cũng có những “ngôn ngữ” riêng của họ. Điều này gây trở ngại cho một người mới vào
để có thể hiểu được những việc đang được tiến hành. Hơn nữa, trong lĩnh vực phần
mềm, nhiều khi khó có thể hiểu được nếu chỉ xem xét các đoạn mã lệnh. Ví dụ như sự
phân cấp của các lớp, ta có thể phải duyệt rất nhiều đoạn lệnh để hiểu được sự phân cấp
của các lớp. Và nếu như người lập trình không mô tả các ý tưởng mà anh ta đã xây
dựng thành mã lệnh thì nhiều khi cách tốt nhất là xây dựng lại trong trường hợp một
người khác đảm nhận tiếp nhiệm vụ khi anh ta rời khỏi nhóm.
Xây dựng mô hình sử dụng ngôn ngữ UML đã giải quyết được các khó khăn
trên.Khi trở thành một chuẩn trong việc lập mô hình, mỗi kí hiệu mang một ý nghĩa rõ

rang và duy nhất, một nhà phát triển có thể đọc được mô hình xây dựng bằng UML do
một người khác viết.Những cấu trúc mà việc nắm bắt thông qua đọc mã lệnh là khó
khăn nay đã được thực hiện trực quan.Một mô hình rõ ràng, sáng sủa làm tăng khả năng
giao tiếp, trao đổi giữa các nhà phát triển.
2.1.2.2 UML là ngôn ngữ để chi tiết hóa
Có nghĩa là xây dựng các mô hình một các tỉ mỉ, rõ ràng, đầy đủ ở các mức độ chi
tiết khác nhau. Đặc biệt là UML thực hiện việc chi tiết hoá tất cả các quyết định quan
trọng trong phân tích, thiết kế và thực thi một hệ thống phần mềm.
2.1.2.3 UML là ngôn ngữ dùng để sinh ra mã ở dạng nguyên mẫu
Các mô hình xây dựng bởi UML có thể ánh xạ tới một ngôn ngữ lập trình cụ thể như
: Java, C++… thậm chí cả các bảng trong một CSDL quan hệ hay CSDL hướng đối
tượng.
Việc các yêu cầu có khả năng thường xuyên thay đổi trong quá trình phát triển hệ
thống dẫn đến việc các cấu trúc và hành vi của hệ thống được xây dựng có thể khác mô
hình mà ta đã xây dựng. Điều này có thể làm cho một mô hình tốt trở nên vô nghĩa vì nó
không còn phản ánh đúng hệ thống nữa. Cho nên phải có một cơ chế để đồng bộ xhóa
giữa mô hình và mã lệnh.
UML cho phép cập nhật một mô hình từ các mã thực thi ( ánh xạ ngược). Điều này
tạo ra sự nhất quán giữa mô hình của hệ thống và các đoạn mã thực thi mà ta xây dựng
cho hệ thống đó.
2.1.2.4 UML là ngôn ngữ dùng để lập và cung cấp tài liệu
Một tổ chức phần mềm ngoài việc tạo ra các đoạn mã lệnh( thực thi) thì còn tạo ra
các tài liệu sau:
• Ghi chép về các yêu cầu của hệ thống
• Kiến trúc của hệ thống
• Thiết kế
• Mã nguồn
• Kế hoạch dự án
• Test
• Các nguyên mẫu

• …
2.1.3 Các loại biểu đồ UML
2.1.3.1 Biểu đồ lớp(class diagram)
Bao gồm một tập hợp các lớp, các giao diện, các collaboration và mối quan hệ giữa
chúng. Nó thể hiện mặt tĩnh của hệ thống.
2.1.3.2 Biểu đồ đối tượng(Object diagram)
Bao gồm một tập hợp các đối tượng và mối quan hệ giữa chúng. Đối tượng là một
thể hiện của lớp, biểu đồ đối tượng là một thể hiện của biều đồ lớp.
2.1.3.3 Biểu đồ use case
Khái niệm actor: là những người, hệ thống khác ở bên ngoài phạm vi của hệ thống
mà có tương tác với hệ thống.
Biểu đồ Use case bao gồm một tập hợp các Use case, các actor và thể hiện mối quan
hệ tương tác giữa actor và Use case. Nó rất quan trọng trong việc tổ chức và mô hình
hóa hành vi của hệ thống.
2.1.3.4 Biểu đồ trình tự(Sequence Diagram)
Là một dạng biểu đồ tương tác (interaction), biểu diễn sự tương tác giữa các đối
tượng theo thứ tự thời gian. Nó mô tả các đối tượng liên quan trong một tình huống cụ
thể và các bước tuần tự trong việc trao đổi các thông báo(message) giữa các đối tượng
đó để thực hiện một chức năng nào đó của hệ thống.
2.1.3.5 Biểu đồ hợp tác (Collaboration)
Gần giống như biểu đồ Sequence, biểu đồ Collaboration là một cách khác để thể hiện
một tình huống có thể xảy ra trong hệ thống. Nhưng nó tập trung vào việc thể hiện việc
trao đổi qua lại các thông báo giữa các đối tượng chứ không quan tâm đến thứ tự của
các thông báo đó. Có nghĩa là qua đó chúng ta sẽ biết được nhanh chóng giữa 2 đối
tượng cụ thể nào đó có trao đổi những thông báo gì cho nhau.
2.1.3.6 Biểu đồ chuyển trạng thái (Statechart)
Chỉ ra một máy chuyển trạng, bao gồm các trạng thái, các bước chuyển trạng và các
hoạt động. Nó đặc biệt quan trọng trong việc mô hình hóa hành vi của một lớp giao
diện(interface class) hay collaboration và nó nhấn mạnh vào các đáp ứng theo sự kiện
của một đối tượng, điều này rất hữu ích khi mô hình hóa một hệ thống phản

ứng(reactive).
2.1.3.7 Biểu đồ hoạt động(Activity)
Là một dạng đặc biệt của biểu đồ chuyển trạng. Nó chỉ ra luồng đi từ hoạt động này
sang hoạt động khác trong một hệ thống. Nó đặc biệt quan trọng trong việc xây dựng
mô hình chức năng của hệ thống và nhấn mạnh tới việc chuyển đổi quyền kiểm soát
giữa các đối tượng.
2.1.3.8 Biểu đồ thành phần (Component)
Chỉ ra cách tổ chức và sự phụ thuộc của các thành phần(component). Nó liên quan
tới biểu đồ lớp, trong đó một thành phần thường ánh xạ tới một hay nhiều lớp, giao diện
, collaboration.
2.2 Ngôn ngữ ràng buộc đối tượng (OCL)
OCL (Object constraint language) là ngôn ngữ xây dựng mô hình phần mềm được
định nghĩa như một chuẩn thêm vào UML cho phân tích và thiết kế hướng đối tượng .
Các biểu thức viết trong OCL phụ thuộc vào các kiểu lớp, giao diện, …) được định
nghĩa trong các biểu đồ UML.
Các biểu thức viết trong OCL thêm các thông tin quan trọng cho các mô hình hướng
đối tượng. Các thông tin này thường khôn thể biểu diễn trong biểu đồ. Trong UML
phiên bản 1.1 các thông tin này được giới hạn bởi các ràng buộc, mỗi ràng buộc được
định nghĩa như một hạn chế về giá trị nhận được( một hay nhiều) của mộ hệ thống hay
mô hình hướng đối tượng. Trong UML phiên bản 2, một mô hình có thể chứa nhiều
thông tin thêm hơn là chỉ có ràng buộc. Tất cả các công việc như định nghĩa truy vấn,
các giá trị tham chiếu, các quy tăc nghiệp vụ hay các điều kiện trạng thái được viết bằng
biểu thức trong một mô hình. OCL là ngôn ngữ chuẩn trong đó các biểu thức được viết
một cách rõ ràng dễ hiểu.
Một mô hình thường có những thiếu sót do những hạn chế của các biểu đồ. Một biểu
đồ đơn giản không thể biểu diễn hết các phát biểu đặc tả.
Hình 2: Mô hình UML không biểu diễn hết đặc tả
Trong mô hình, quan hệ giữa lớp Flight và lớp Person , phía lớp Person có bản số là
0…* tức là số khách hang là không giới hạn. Trong thực thế số khách hàng bị giới hạn
bởi số ghế mà máy bay có, và giới hạn này không thể biểu diễn trong biểu đồ. Trong ví

dụ này có một cách chỉ định ràng buộc về bản số thể hiện là thêm vào biểu đồ ràng buộc
OCL sau:
context Flight
inv: passengers->size() <= plane.numberOfSeats.
2.3 Lập trình hướng khía cạnh (Aspect Oriented Programming)
2.3.1 Phương pháp lập trình hướng khía cạnh
Có lẽ các khái niệm về lập trình hướng khía cạnh (AOP) hiện nay đã được nhiều
người biết đến, vì vậy ở đây tôi sẽ chỉ trình bày lại ngắn gọn các khái niệm cơ bản và
đặc điểm chính của AOP. Để trả lời được câu hỏi AOP là gì? Tại sao phải có AOP?
chúng ta sẽ bắt đầu tìm hiểu sự hạn chế của các phương pháp lập trình hiện tại trong
việc đáp ứng các yêu cầu ngày càng phức tạp của các hệ thống phần mềm.
2.3.1.1 Sự hạn chế của lập trình hướng đối tượng(OOP)
Như chúng ta đ ã bi ết trong OOP người ta cố gắng mô tả thế giới thực thành các đối
tượng với các thuộc tính và phương thức; cùng với các tính chất của lập trình hướng đối
tượng như: tính trừu tượng, tính đóng gói, tính kế thừa và đa h ình đã làm thay đổi
hoàn toàn ngành công nghiệp phần mềm.
Hình 3: OOP
Ta xét một ví dụ cụ thể xây dựng chương trình vẽ hình đơn giản.
Một phân tích đơn giản cho yêu cầu của bài toán:
- Các hình học cơ bản : điểm, đoạn thẳng, hình chữ nhật , hình tròn,…
- Hiển thị các hình ở các vị trí khác nhau trong khung vẽ
- Phải cập nhật lại hình tại vị trí mới mỗi khi di chuyển, co giãn hình.
Sử dụng OOP ta sẽ mô hình hóa yêu cầu thành các đối tượng sau :
- Lớp Shape: là một lớp Abstract chứa phương thức moveBy(int,int) di chuyển
hình
- Lớp Display: hiển thị hình ảnh.
- Lớp Point: mô tả 1 điểm hình học chứa hai thuộc tính là tọa độ x, y được kế
thừa từ lớp Shape.
- Lớp Line: mô tả 1 đoạn thẳng, chứa 2 thuộc tính là điểm đầu và điểm cuối
của đoạn thẳng và được kế thừa từ lớp Shape.

Dưới đây là sơ đồ lớp của bài toán
Figure 1
Hình 4: Sơ đồ lớp của bài toán vẽ hình
Mô hình hóa thành các lớp như vậy ta thấy bài toán đã tương đối ổn. Bây giờ vấn đề
đặt ra là mỗi khi ta thay đổi tọa độ của một điểm hay co giãn hình, di chuyển hình ta lại
phải vẽ lại hình ở vị trí mới – tức là phải update lại Display.