một số mô thức lập trình

ĐẠI HỌC BÁCH KHOA HÀ NỘI

Bộ môn: Kĩ thuật lập trình

TÌM HIỂU VỀ MỘT SỐ MÔ HÌNH LẬP TRÌNH

Giảng viên: Vũ Đức Vượng

Thực hiện: Sinh viên: Đỗ Bá Mạnh SHSV:20111830 Lớp CNTT-TT 1.1

Hà Nội, 1/2013

KĨ THUẬT LẬP TRÌNH

Lời nói đầu.Bất kỳ một ngôn ngữ lập trình nào cũng đều mang tính logic cao và tuân theo những quy chuẩn cơ bản về toán học. Tuy vậy, mỗi ngôn ngữ lại có những phương thức riêng để thực hiện những quy chuẩn đó, đặc biệt là trên các lĩnh vực như hàm (function), biến (variable), phương thức (method) và đối tượng (object). Bên cạnh sự đa dạng của ngôn ngữ lập trình, cũng dần có rất nhiều mô hình lập trình được ra đời, trong đó phổ biến nhất có thể kể đến như: Lập trình hướng đối tượng (object-oriented programming), lập trình thủ tục(procedural programming) và lập trình cấu trúc (structured programming). Mỗi một mô hình lập trình lại có những đặc trưng riêng về cách sử dụng cũng như tính trừu tượng hóa đối với các quá trình xác định.

Các nhóm khác nhau trong công nghệ phần mềm đề xướng các phương pháp khác nhau, các ngôn ngữ lập trình khác nhau tức là các mô hình lập trình khác nhau. Một số ngôn ngữ được thiết kế để hỗ trợ một mô hình đặc thù (Java hỗ trợ lập trình hướng đối tượng trong khi Haskell hỗ trợ lập trình chức năng). Một số ngôn ngữ khác lại hỗ trợ nhiều mô hình (như Python và Common Lisp).

Một số mô hình lập trình cấm các thao tác mà chính ngôn ngữ đó có. Chẳng hạn, lập trình cấu trúc không cho phép sử dụng lệnh goto. Quan hệ giữa các mô hình lập trình và các ngôn ngữ lập trình có thể phức tạp vì một ngôn ngữ có thể hỗ trợ nhiều mô hình lập trình. Thí dụ như C++ được thiết kế để hỗ trợ các phần tử của lập trình thủ tục, lập trình hướng đối tượng và lập trình tiêu bản.

Mặc dù vậy, những người thiết kế và những người lập trình sẽ quyết định làm thế nào để xây dựng một chương trình dùng các phần tử của mô hình nào đó. Người ta có thể viết một chương trình hoàn toàn theo kiểu lập trình thủ tục trong C++, cũng có thể viết chương trình hoàn toàn hướng đối tượng, hay viết chương trình có các phần tử của cả hai mô hình.

Ở thời kỳ đầu, công nghệ phần mềm hoàn toàn dựa trên những thao tác lập trình bằng mã nhị phân hoặc mã máy, mà đại diện là các giá trị 0 và 1. Điều này khiến cho quá trình thiết kế, kiểm soát sự hoạt động cũng như sửa lỗi đối với

1


một ứng dụng trở nên vô cùng rắc rối và không hiệu quả. Chúng ta coi những phương thức lập trình ở thời điểm này thuộc mô hình lập trình bậc thấp (low-level programming paradigm). Về sau, cùng với sự phát triển của công nghệ, những hạn chế của giai đoạn đầu tiên dần được xóa bỏ với sự ra đời của các ngôn ngữ lập trình thế hệ thứ 3 là COBOL, Fortran và BASIC, đồng thời, một mô hình lập trình mới cũng xuất hiện và vẫn tiếp tục được sử dụng hiệu quả và phổ biến cho đến ngày nay, đó là mô hình lập trình thủ tục (procedural paradigm). Dần dần, chúng ta chứng kiến sự phát triển mạnh mẽ về số lượng của các mô hình lập trình, mà cơ bản có thể kể đến các mô hình sau:

Lập trình cấu trúc - Structured programming. Lập trình chức năng - Functional programming. Lập trình logic - Logical paradigm Lập trình trực quan - Visual programming. Lập trình song song - Parallel programming. Lập trình phân tán - Distributed programming. Lập trình tương tranh - Concurrent programming. Lập trình định hướng đối tượng - Component-oriented programming .

Lập trình cực độ - Extreme programming.

….

2


SƠ LƯỢC VỀ MỘT SỐ MÔ HÌNH LẬP TRÌNH PHỔ BIẾN

1. Functional programming.

Đặc điểm:

Nguyên lý và ý tưởng: Toán học và lý thuyết về hàm. Các giá trị đã được tạo là không thể biến đổi. Trừu tượng hóa một biểu thức thành một hàm và ngược lại, một hàm có

thể được tính toán như một biểu thức. Hàm là lớp giá trị đầu tiên. Hàm là những giá trị hoàn chỉnh, tương tự như số, danh sách... Thích hợp với những tính toán theo yêu cầu. Mở ra những khả năng mới.

Functional Programming là thể loại lâu đời nhất trong ba paradigm lập trình chính. Ngôn ngữ FP đầu tiên là IFP, được phát minh vào năm 1955, một năm trước khi có Fortran. Sau đó, LISP ra đời năm 1958, một năm trước khi có COBOL. Cả Fortran và COBOL đều là những ngôn ngữ imperative (hay còn gọi là procedural). Chúng đặc biệt thành công khi được ứng dụng vào tính toán khoa học và nghiệp vụ, và trở thành paradigm thống trị trong suốt 30 đầu của kỉ nguyên thông tin. Vào những năm 1970, Object-Oriented paradigm bắt đầu phát triển. Cùng với sự trưởng thành của các ngôn ngữ lập trình hướng đối tượng, OO trở thành paradigm được sử dụng phổ biến nhất cho đến ngày hôm nay.

Từ những năm 1950, mặc dù vẫn phát triển mạnh mẽ và liên tục với các đại diện như SML, OCaml, APL và Clean, thì FP vẫn chỉ được sử dụng cho mục đích học thuật và nghiên cứu là chủ yếu. Imperative đạt được thành công bước đầu nhờ vào những chỉ thị đơn giản. OO thành công nhờ vào khả năng mô hình hóa các bài toán phức tạp. Còn FP có khả năng gì, tại sao dù ra đời sớm nhưng lại không mang lại thành công như mong đợi?

3


FP xem chương trình là một tập hợp các hàm nhận vào đối số và trả về giá trị. Không giống như Imperative, FP không tạo ra hiệu ứng phụ và sử dụng đệ qui thay cho vòng lặp. Hàm trong FP rất giống với hàm

trong toán học vì nó không làm thay đổi trạng thái của chương trình.

Một đại lượng khi được gán giá trị thì không bao giờ thay đổi giá trị đó. Hàm không sửa đổi giá trị của đối số được truyền vào, và giá trị do hàm trả

về hoàn toàn là một giá trị mới.

Về mặt kĩ thuật cài đặt bên dưới, khi giá trị được gán vào một vùng nhớ thì được đánh dấu là đã sử dụng và không ghi đè lên nữa. Để tạo ra kết quả trả về, các hàm sao chép giá trị rồi chỉnh sửa trên các bản sao đó, không làm ảnh hưởng đến giá trị ban đầu, rồi trả về bản sao đã được chỉnh sửa. Các đại lượng không còn được hàm nào tham chiếu đến sẽ tự động bị hủy để giải phóng bộ nhớ (đây là ý tưởng của bộ thu gom rác trong Java và.NET).

Cơ sở toán học cho FP rất tường minh, cung cấp giải pháp logic và ngắn gọn cho các vấn đề tính toán. Tuy nhiên, do nó không linh hoạt thay đổi trạng thái và chuyên sử dụng đệ qui khiến người ta ưa chuộng các paradigm khác hơn để xử lý các thao tác tính toán thông dụng.

2. Logical paradigm4


Trong lập trình logic, ta có thể sử dụng các vị từ để định nghĩa các khái niệm của tất cả các môn khoa học khác.

Ví dụ định nghĩa một số nguyên tố:

Số nguyên tố N là một số nguyên lớn hơn 1, chỉ chia hết cho 1 và chính nó.

Để xét xem số N có phải là số nguyên tố hay không, người ta thường sử dụng dấu hiệu nhận biết: Số nguyên tố là một số nguyên dương, không chia hết cho mọi số nguyên tố nhỏ hơn nó và 2 là số nguyên tố nhỏ nhất.

Dấu hiệu này có thể mô tả bằng các vị từ như sau:

- 2 là một số nguyên tố.

- N là một số nguyên tố nếu N>0, M là số nguyên tố nào đó, M<N và N không chia hết cho M.

Khi mô tả bài toán dưới dạng logic vị từ, ta có thể yêu cầu hệ thống tìm kiếm các lời giải liên quan đến các khai báo đó. Bài toán cần giải được xem là “mục tiêu” mà hệ thống phải chứng minh trên cơ sở các tri thức đã được khai báo.

Như thế, toàn bộ các ký hiệu của ngôn ngữ lập trình suy về một công thức đặc biệt:

- Phát sinh từ một yêu cầu.- Nhằm chứng minh một mục tiêu. Để trả lời cho câu hỏi đó hệ thống xem nó

như là một “đích” và cố chứng minh “đích” đó bằng cách tạo những suy diễn trên cơ sở các tri thức đã khai báo.

Một ngôn ngữ logic có thể được dùng trong giai đoạn đặc tả yêu cầu của quy trình xây dựng một sản phẩm phần mềm. Hơn thế nữa, logic vị từ cho phép biểu diễn hầu hết các khái niệm và các định lý trong các bộ môn khoa học.

3. Visual programming

5


Như chúng ta đã biết, mỗi loại máy tính (sử dụng loại CPU – Central Processing Unit xác định) chỉ có thể hiểu và thực hiện trực tiếp được các lệnh cũng như chương trình theo một loại ngôn ngữ dành riêng được gọi là ngôn ngữ máy. Tuy nhiên, nếu triển khai các ứng dụng trong thực tế mà phải viết chương trình trực tiếp bằng ngôn ngữ máy thì sẽ rất phức tạp, đòi hỏi thời gian và công sức rất lớn, nhiều khi không thể thực hiện được. Vì vậy, người ta tìm cách xây dựng một ngôn ngữ lập trình riêng gần với các ngôn ngữ tự nhiên, thuận lợi cho việc triển khai các ứng dụng. Khi thực hiện các chương trình bằng ngôn ngữ này phải qua một bước dịch chương trình đó sang ngôn ngữ máy để nó có thể thực hiện. Từ trước đến nay có rất nhiều ngôn ngữ lập trình được ra đời và phục vụ đắc lực cho việc triển khai các ứng dụng trên máy tính.

Trong giai đoạn đầu, các ngôn ngữ lập trình tuy dễ sử dụng hơn ngôn ngữmáy nhưng rất khó với các lập trình viên vì chưa đủ mạnh để dễ dàng triển khai các thuật toán. Chương trình chưa có tính cấu trúc chặt chẽ về mặt dữ liệu cũng như tổ chức chương trình. Vì vậy, việc triển khai các ứng dụng trong thực tế bằng các ngôn ngữ lập trình này là rất khó khăn. Giai đoạn 2 là thời kỳ của các ngôn ngữ lập trình có cấu trúc. Các ngôn ngữ lập trình này có đặc điểm là có tính cấu trúc chặt chẽ về mặt dữ liệu và tổ chức chương trình. Một loạt các ngôn ngữ lập trình có cấu trúc ra đời và dược sử dụng rộng rãi như : PASCAL, C, BASIC... Giai đoạn 3 là thời kỳ của lập trình hướng đối tượng và phương pháp lập trình có bước biến đổi mạnh. Trong các ngôn ngữ lập trình có cấu trúc thì một ứng dụng bao gồm hai thành phần riêng là dữ liệu và chương trình. Tuy chúng có quan hệ chặt chẽ nhưng là hai đối tượng riêng biệt. Trong phương pháp lập trình hướng đối tượng thì mỗi một đối tượng lập trình sẽ bao hàm cả dữ liệu và phương thức hành động trên dữ liệu đó. Vì vậy, việc lập trình sẽ đơn giản và mang tính kế thừa cao, tiết kiệm được thời gian lập trình. Tuy nhiên, với các phương pháp lập trình trên đều đòi hỏi lập trình viên phải nhớ rất nhiều câu lệnh với mỗi lệnh có một cú pháp và tác dụng riêng, khi viết chương trình phải tự lắp nối các lệnh để có một chương trình giải quyết từng bài toán riêng biệt. Trong xu hướng phát triển mạnh mẽ hiện nay của tin học, số người sử dụng máy tính tăng lên rất nhanh và máy tính được sử dụng trong hầu hết các lĩnh vực của đời sống nên đòi hỏi các ngôn ngữ lập trình cũng phải đơn giản, dễ sử dụng và mang tính đại chúng cao. Chính vì vậy phương pháp lập trình trực quan ra đời.

6


Đặc điểm của các ngôn ngữ lập trình trực quan là dễ sử dụng, triển khai các ứng dụng một cách nhanh chóng.

Đặc điểm: Cho phép xây dựng chương trình theo hướng sự kiện (Event-Driven

Programming, nghĩa là một chương trình ứng dụng được viết theo kiểu này đáp ứng dựa theo tình huống xảy ra lúc thực hiện chương trình. Tình huống này bao gồm người sử dụng ấn một phím tương ứng, chọn lựa một nút lệnh hoặc gọi một lệnh từ một ứng dụng khác chạy song song cùng lúc.

Người lập trình trực tiếp tạo ra các khung giao diện (interface), ứng dụng thông qua các thao tác trên màn hình dựa vào các đối tượng (ojbect) như hộp hội thoại hoặc nút điều khiển (control button), những đối tượng này mang các thuộc tính (properties) riêng biệt như: màu sắc, Font chữ.. mà ta chỉ cần chọn lựa trên một danh sách cho sẵn.

Khi dùng các ngôn ngữ lập trình trực quan ta rất ít khi phải tự viết các lệnh, tổ chức chương trình... một cách rắc rối mà chỉ cần khai báo việc gì cần làm khi một tình huống xuất hiện.

Máy tính sẽ dựa vào phần thiết kế và khai báo của lập trình viên để tự động tạo lập chương trình.

7


4. Parallel programming.

Tính toán song song (Parallel Computing) là việc chia một công việc ra thành các công việc nhỏ và cho các công việc này thực hiện đồng thời với nhau bởi các hệ thống có nhiều bộ vi xử lý (multiprocessor) hay bộ vi xử lý đa nhân (multicore) nhằm giảm thời gian thực hiện công việc đó xuống. Việc lập trình để tách ra các công việc nhỏ và sắp xếp để xử lý song song thì được gọi là lập trình song song.

“Số lượng transistor trong bộ vi xử lý sẽ tăng lên gấp đôi sau mỗi 24 tháng.” Gordon Moore - sáng lập viên của tập đoàn Intel.

Cùng với định luật Moore, các máy tính hiện nay đã được trang bị các bộ vi xử lý đa nhân mạnh mẽ.

Tuy nhiên, để tận dụng được sức mạnh đó đòi hỏi các lập trình viên phải tận dụng được hết các nhân trong bộ vi xử lý. Vì vậy, thay vì lập trình tuần tự như trước đây chỉ sử dụng một nhân của bộ vi xử lý thì người lập trình viên ngày nay phải dùng kỹ thuật lập trình song song để tận dụng hiệu suất của bộ vi xử lý đa nhân.

Việc lập trình song song không phải lúc nào cũng mang lại hiệu suất cao cho chương trình. Đối với các công việc chỉ tốn ít hiệu suất thì việc dùng lập trình song song sẽ không mang lại kết quả như mong đợi do khoảng thời gian để khởi tạo và quản lý các tiến trình song song gây nên.

Trong quá trình lập trình song song, lập trình viên khó tránh khỏi việc các tiến trình cùng sử dụng chung một dữ liệu điều này sẽ gây ra xung đột dữ liệu hoặc làm dữ liệu bị sai lệch do đó lập trình viên cần phải chú ý và áp dụng các kỹ thuật lập trình để giải quyết vấn đề này.

Bộ vi xử lý có nhiều nhân sẽ tăng tốc chương trình song song tuy nhiên không có nghĩa là nó sẽ tăng lên 100% trên một nhân (core) được thêm vào. Thậm chí chương trình song song không hề tăng hiệu suất lên trong một số trường hợp. Vì vậy lập trình viên phải biết quyết định khi nào sử dụng lập trình song song bằng cách sử dụng các công cụ đo lường để xác định được tốc độ thực thi của chương trình.

8


Lập trình song song là một công việc rất phức tạp so với lập trình tuần tự thông thường, người phát triển phải thực hiện một quá trình “song song hóa”, biến đổi các chương trình tuần tự thành chương trình song song có khả năng tận dụng tối đa sức mạnh của hệ thống.

Quá trình song song hóa gồm ba giai đoạn bước chính :

Phân chia chương trình thành các công việc con (Sub-task decomposition). Phân tích sự phụ thuộc (Dependence analysic). Định thời các công việc (Task scheduling).

Nói một cánh dễ hiểu thì lập trình song song là lập trình để chạy được đa luồng với các dòng CPU đa nhân hiện nay ( core i3, core i5, core i7,…)

5. Concurrent programming

Lập trình tương tranh là một trong những kỹ thuật quan trọng và cũng là một thách thức. Một mặt, nó đem lại khả năng sử dụng hiệu quả cho những hệ thống song song và phân tán. Mặt khác, những rủi ro trong việc tương tác giữa các tiến trình thực hiện đồng thời có thể gây ra những lỗi phần mềm không dễ dàng để tìm ra.

Trong lập trình tương tranh, một số dòng lệnh có thể được thực hiện đồng thời. Mỗi dòng lệnh là một chương trình tuần tự, ngoại trừ một thực tế là các dòng lệnh có thể giao tiếp và gây trở ngại lẫn nhau. Mỗi một dòng lênh là một luồng ( thread ), các chương trình tuần tự còn gọi là chương trình đơn luồng, còn chương trình viết theo phương pháp tương tranh là chương trình đa luồng.

Đặc điểm:

9


Người dùng có thể tương tác với các ứng dụng khi tiến trình đang thực thi. Những tiến trình chạy thời gian dài làm trì hoãn các tiến trình ngắn. Các chương trình phức tạp được thực hiện tốt hơn trên các bộ xử lý đa

luồng. Những tiến trình đòi hỏi điều kiện tiên quyết có thể tạm dừng và đợi đến

khi đáp ứng được để tiếp tục xử lý.

6. Distributed programming.

Lập trình phân tán là một dạng của lập trình song song (tính toán song song). Lập trình song song tạo ra mối liên hệ giữa máy tính và các đơn vị tính toán, khiến chúng hoạt động đồng thời đối với một vấn đề cụ thể (dự báo thời tiết chẳng hạn). Các đơn vị tính toán có thể đặt rất gần nhau hoặc tách rời nhau. Khi các đơn vị tính toán được đặt tách rời, ta gọi đó là lập trình phân tán. Với mô hình lập trình này, các đơn vị tính toán thường rất khác nhau, cũng như sự khác nhau giữa các hệ điều hành và thiết lập mạng máy tính. Những yếu tố đó khiến cho việc lập trình các tính toán của máy tính trở nên tương đối phức tạp và khó khăn.

Lập trình mạng phân tán, thường có 2 khái niệm chính: peer to peer và client - server... peer to peer là lập trình ngang hàng giữa 2 máy tính... còn lập trình client - server là lập trình cho phép n máy client kết nối tới m máy server - đây cũng là mô hình chúng ta sẽ gặp nhiều trong thực tế …

Có thể chia lập trình mạng thành 3 cấp độ, căn cứ theo mức độ thân thiện với developer và khả năng triển khai:

Mức thấp nhất là lập trình sử dụng socket - có thể truyền từng byte, từng stream lên trên mạng, ứng dụng này thường gặp trong các ứng dụng mạng cỡ nhỏ (vd: trong 2 máy tính, trong 1 mạng LAN...).

10


Mức cao hơn là lập trình sử dụng, triển khai ứng dụng theo mô hình dịch vụ (service) - quản lí mạng theo mô hình: kết nối, tạo tham chiếu client trên server và trả về, gọi hàm và truyền dữ liệu thông qua proxy của đối tượng trả về từ server (vd: RMI trên Java hay Remoting trên.NET...), mô hình này thường gặp trong các ứng dụng mạng cỡ trung bình và lớn, đòi hỏi tính performance cao (vd: các ứng dụng mạng đòi hỏi kết nối nhiều - liên tục và sử dụng diện rộng như các dịch vụ chat, game online...), ưu điểm chính của mô hình này là tính performance cao, bảo mật, nhưng nhược điểm là tính đa nền (multiplatform) và tính khả chuyển chưa cao (server và client phải cùng 1 công nghệ phát triển.)

Mức cao nhất là triển khai ứng dụng theo mô hình triển khai trên web, điển hình nhất ta có thể thấy là các web application và web service, mới nhất giờ có công nghệ WCF của M$ (tổng hợp tất cả trong 1)... mô hình này cho phép triển khai trên diện rộng, phục vụ lượng khách hàng lớn... nhưng cũng có nhược điểm là tính performance chưa cao, bù lai, nó có khả năng mềm dẻo (flexibility) cao (server và client không cần sử dụng chung một công nghệ). Chúng ta thường thấy những ứng dụng loại này trong các ứng dụng được cung cấp từ một nhà cung cấp nào đó (vd: các số liệu chứng khoán, thời tiết …).

11


7. Extreme programming.

Extreme Programing là nổi tiếng nhất của phương thức Agile (Agile Method). Nó được hình thành bởi một tập các thực nghiệm (practice) đơn giản nhưng phụ thuộc lẫn nhau. Những practice này làm việc với nhau để hình thành một dạng tổng quát hơn các thành phần của nó.

Khách hàng là thành viên của nhóm phát triển (Customer team member)Chúng ta mong muốn khách hàng và nhóm phát triền làm việc chung với nhau để họ hiểu các vấn đề của nhau và cùng giải quyết các vấn đề đó. V y ai là khách hàng ? Khách hàng của một nhóm XP là một hoặc một nhóm ângười định nghĩa và xác định độ ưu tiên của chức năng hệ thống (hay sản phẩm). Đôi khi khách hàng là nhóm nhà phân tích nghiệp vụ hoặc chuyên gia marketing làm việc cùng một công ty phần mềm với nhóm phát triển. Đôi khi khách hàng là một đại diện của người dùng. Đôi khi khách hàng cũng chính là người trả tiền. Nhưng trong một dự án XP, bất kể khách hàng là ai thì họ cũng là một thành viên của nhóm phát triển. Tình huống tốt nhất là khách hàng làm việc với nhóm phát triển trong cùng một phòng. Hoặc chí ít là làm việc ở nơi nào đó cách độ 100 feet so với phòng làm việc của nhóm phát triển. Khoảng cách càng xa thì càng khó thỏa mãn điều kiện "Customer team member". Nếu khách hàng làm việc trong môt tòa nhà khác hoặc ở một quốc gia khác thì càng khó mà yêu cầu họ tham gia cùng với nhóm. Chúng ta sẽ làm gì nếu khách hàng không thể ở gần nhóm phát triển ? Lời khuyên của tôi là hãy tìm ai đó sẵn lòng làm việc chung và có thể đứng ở vai trò của một khách hàng thực thụ.

Câu chuy n ngươi dung (User Stories)êĐể lên kế hoạch cho một dự án, chúng ta phải biết về yêu cầu, nhưng chúng ta không nên biết nhiều lắm. Với mục đích lập kế hoạch, chúng ta chỉ cần biết đủ về yêu cầu để ước lượng chúng. Bạn có thể nghĩ rằng để có thể ước lượng, bạn cần biết tất cả các chi tiết, nhưng điều này thường không đúng. Bạn cần biết rằng thực tế có những <i>chi tiết</i> đó, và bạn phải biết rằng các chi tiết đó vô cùng hỗn tạp, nhưng bạn không cần tới các đặc tả của chúng.

12


Đặc tả chi tiết của một yêu cầu thì luôn thay đổi theo thời gian, đặc biệt là khi khách hàng bắt đầu nhìn thấy hệ thống vận hành như thế nào. Không có cách xác định yêu cầu nào tốt hơn cách quan sát hệ thống được áp dụng vào thực tế như thế nào. Vì vậy, thu thập đặc tả chi tiết yêu cầu quá sớm trước khi cài đặt hệ thống là quá vội vã và uổng phí. Khi áp dụng XP, chúng ta sẽ cảm nhận được chi tiết của yêu cầu qua các cuộc trao đổi (nói chuyện) với khách hàng, nhưng chúng ta sẽ không thu thập các chi tiết đó. Khách hàng sẽ viết vài chữ (đã được thương lượng với chúng ta) lên một tấm giấy ghi chú (index card). Tờ card này sẽ nhắc chúng ta nhớ về cuộc trao đổi này. Cũng vào khoảng thời gian này, nhóm phát triển sẽ viết lên tờ card đó các ước lượng. Họ ước lượng dựa trên cảm giác về các chi tiết nhận được trong cuộc đối thoại User Story là dấu hiệu ghi nhớ cuộc đối thoại về yêu cầu. Nó là công cụ lập kế họach mà khách hàng dùng để lên lịch trình cài đặt các yêu cầu dựa trên cơ sở mức độ ưu tiên và chi phí ước lượng.

Chu kỳ ngắn (Short Cycles)Một dự án XP sẽ giao sản phẩm dở dang (hay dự án đang thực hiện, cùng dịch từ chữ working project) mỗi 2 tuần. Mỗi bước lặp 2 tuần này sản xuất ra một phần mềm dở dang đáp ứng một số yêu cầu nào đó của khách hàng. Tại thời điểm cuối của bước lập, hệ thống được demo cho khách hàng xem và nhận phản hồi của họ. Kế hoạch bước lặp:

Mỗi bước lặp thường kéo dài 2 tuần. Nó đại diện cho một lần giao hàng thử, có thể sẽ được hoặc không được thêm vào sản phẩm chính thức. Nó là một tập các user story được chọn bởi khách hàng dựa trên chi phí do nhóm phát triển đưa ra. Nhóm phát triển đưa ra chi phí cho một bước lặp bằng cách đo chi phí của các bước lặp họ đã làm trước đó. Khách hàng chọn tùy ý số lượng story cho bước lặp sao cho tổng chi phí ước lượng không vượt quá ngân sách. Mỗi khi một bước lập được khởi động, khách hàng đồng ý không thay đổi định nghĩa của story và độ ưu tiên. Trong suốt thời gian này, nhà phát triển tự do cắt các story thành các nhiệm vụ (task) và tự do cài đặt các task này tùy theo thuận lợi về mặt kỹ thuật và kinh doanh.

13


Kế họach phát hành: Nhóm XP thường tạo kế hoạch phát hành tương ứng với mỗi 6 bước lặp. Một bản phát hành thường là thành quả của 3 tháng làm việc. Nó đại diện cho 1 lần giao hàng chính và thường sẽ được đưa vào sản phẩm. Một bản phát hành cũng bao gồm một tập các story được phân độ ưu tiên bởi khách hàng dựa trên ngân sách mà nhóm phát triển đưa ra. Nhóm phát triển xây dựng ngân sách cho 1 bản phát hành bằng cách đo chi phí tiêu tốn của những phiên bản phát hành trước. Khách hàng có thể chọn số lượng bất kỳ các story cho 1 bản phát hành sao cho tổng các chi phí ước lượng không vượt quá ngân sách. Khách hàng cũng xác định trình tự các story được cài đặt trong 1 bản phát hành. Nếu muốn, nhóm phát triển cũng có thể đưa ra vài bước lập đầu tiên và xác định xem story nào sẽ được cài đặt trong bước lặp nào. Các bản phát hành không cố định, khách hàng có thể thay đổi nội dung bất kỳ lúc nào. Họ có thể hủy hoặc viết một story mới hoặc thay đổi độ ưu tiên của các story.

Các chương trình kiểm tra sự thỏa mãn yêu cầu của sản phẩm (Acceptance Test) Chi tiết về user story được thu thập trong dạng thức của các acceptance test được đặc tả bởi khách hàng. Các acceptance test của 1 story được viết ngay trước hoặc cùng lúc với việc cài đặt story đó. Chúng được viết theo một ngôn ngữ kịch bản bất kỳ nào cho phép chúng chạy tự động và có thể lặp lại. Ngôn ngữ của acceptance test được phát triển và tiến hóa cùng với hệ thống. Khách hàng có thể thuê nhóm phát triển tạo một hệ thống thực thi kịch bản đơn giản hoặc có thể họ có bộ phận kiểm soát chất lượng (QA) riêng để phát triển nó. Nhiều khách hàng nhờ QA phát triển công cụ cho việc kiểm tra đ thỏa mãn của ôsản phẩm và trực viết các acceptance test. Mỗi khi một acceptace test thành công, nó được thêm vào nhóm của những acceptance test đã thành công trước đó, và không bao giờ được phép thất bại. Nhóm acceptance test tăng trưởng lên và sẽ được chạy nhiều lần trong ngày, hoặc chạy mỗi khi build hệ thống. Nếu như các acceptance test thất bại thì build này được báo cáo là hỏng. Như vậy mỗi khi một yêu cầu được gọi là cài đặt xong thì nó sẽ không bao giờ bị vỡ. Hệ thống chuyển từ trạng thái cũ sang trạng thái

14


mới mà không bao giờ được phép không làm việc (nghĩa là phải thỏa mãn các yêu cầu cũ lẫn mới) lâu hơn vài giờ.

Lập trình theo cặp (Pair Programming)Mã nguồn sản phẩm được viết bởi các cặp lập trình viên làm việc với nhau trên cùng một máy tính. Một thành viên của 1 cặp sẽ giữ bàn phím và đánh code. Thành viên còn lại của cặp sẽ quan sát code được đánh và tìm kiếm lỗi và cải tiến mã. Cả 2 tương tác với nhau một cách liên tục và cả 2 cùng bận rộn cho công việc viết phần mềm. Vai trò được thay đổi thường xuyên. Người giữ phím sẽ mệt mỏi và dẫn đến dễ sai lầm. Người còn lại (trong 1 cặp) sẽ nhận lại bàn phím và điều khiển nó. Bàn phím được hoán đổi nhiều lần giữa 2 người trong 1 giờ. Mã nguồn kết quả được thiết kế và được viết bởi cả 2 người. Công sức của cả hai là như nhau. Mối quan hệ theo cặp sẽ được thay đổi ít nhất 1 lần trong ngày để mỗi lập trình viên được làm việc ít nhất với 2 người trong ngày. Xuyên suốt 1 bước lặp của XP, mỗi thành viên của nhóm phát triển phải làm việc với mọi thành viên khác trong nhóm. Và họ chỉ làm những công việc của trong nội dung của bước lặp đó mà thôi. Điều này tăng cường sự trãi rộng kiến thức cho toàn nhóm. Trong khi kỹ thuật đặc trưng vẫn còn nguyên vẹn và các công việc yêu cầu kỹ thuật đặc trưng vẫn thường được giao cho các chuyên gia thì các chuyên gia này làm việc với hầu hết các thành viên còn lại trong nhóm . Điều này sẽ trải rộng kiến thức cho toàn nhóm để các thành viên khác có thể thay thế cho chuyên gia trong các trường hợp khẩn cấp. Nghiên cứu của Laurie Williams và Nosek đã chỉ ra rằng làm việc theo cặp không những không giảm hiệu năng của đội ngũ lập trình mà nó còn gia giảm đáng kể tỉ lệ sai sót.

Phát triển theo đinh hướng test (Test Driven Development)Tất cả các mã nguồn sản phẩm được viết để làm cho các unit test thành công. Đầu tiên, chúng ta viết 1 unit test thất bại (fail, chạy sai) bởi vì chức năng dự định test vẫn chưa tồn tại. Sau đó chúng ta viết mã để cái test này thành công (pass).

15


Thời gian lặp lại giữa viết test rồi viết code xảy ra rất nhanh, trong khoảng một vài phút. Các b test và mã cùng tăng trưởng, trong đó b test luôn dẫn trước mãô ô một khoảng cách rất ngắn. Kết quả là các b test phát triển cùng lúc với mã sản phẩm. Những bộ test này ôcho phép các lập trình viên kiểm tra chương trình (đang phát triển) có chạy hay không. Nếu một cặp nào đó thưc hiện một thay đổi nhỏ, họ có thể chạy lại các bộ test để chắc chắn rằng ho không làm hỏng các đoạn mã khác. Điều này làm cho công việc refactoring vô cùng thuận tiện. Khi bạn viết mã để các bộ test thành công, thì mã đó được gọi là mã khả kiểm (hay mã có thể test, testable code). Ngoài ra, còn có 1 mục tiêu rất quan trọng là bạn có thể tách bạch các module sao cho chúng có thể được test một cách độc lập. Như vậy, bản thiết kế theo hướng này cho kết quả là mã nguồn ít bị trùng lặp nhất. Các nguyên lý thiết kế OO đóng vai trò là công cụ mạnh mẽ giúp bạn tránh được mã trùng lặp.

Sở hữu tập thể (Collective Ownership) Một cặp có quyền check out và chỉnh sửa, cải tiến một module bất kỳ. Không một lập trình viên nào chịu trách nhiệm cá nhân với một module bất kỳ hoặc một kỹ thuật bất kỳ. Mọi người cùng làm việc với GUI(*). Mọi người cùng làm việc với middle ware. Mọi người cùng làm việc với database. Không ai có nhiều quyền lực hơn người khác về một kỹ thuật hay một module nào đó. Điền này không có nghĩa là XP phản đối chuyên viên. Nếu bạn có kỹ năng về lập trình GUI, hẳn bạn thích các nhiệm vụ liên quan đến GUI, nhưng bạn sẽ được yêu cầu bắt cặp với các nhiệm vụ ở middle ware và database. Nếu bạn quyết định học một chuyên môn thứ hai, bạn có thể đăng ký các nhiệm vụ và làm việc với chuyên gia ở chuyên môn đó. Họ sẽ dạy bạn và bạn sẽ không bị "giam giữ" trong chuyên môn của mình.

Tích hợp liên tục (Continous Intergation) Các lập trình viên check in mã và tích hợp nhiều lần trong ngày. Qui luật rất đơn giản, người đầu tiên sẽ check in, những người sau thì merge. XP sử dụng công cụ quản lý mã (source control) cho phép nhiều người check out môt lúc. Điều này có nghĩa là các lập trình viên được phép check out bất kỳ

16


một module nào đó vào bất kỳ thời điểm nào đó. Khi anh ta check in module (đã được chỉnh sửa), anh ta phải chuẩn bị merge với các thay đổi do một lập trình viên bất kỳ trước đó thưc hiện. Để tránh phải merge quá nhiều trong 1 lúc, các thành viên nên check in thường xuyên. Một cặp sẽ làm một nhiêm vụ trong khoảng 1 hay 2 giờ. Họ tạo các bộ test và mã sản phẩm.Vào một thời điểm thích hợp, có thể là trước khi nhiệm vụ đó được hoàn thành, họ sẽ quyết định check in các đoạn mã. Trước tiên, họ phải làm cho các bô test đều thành công. Sau đó, họ mới tích hợp phần code mới vào phần đã có. Nếu cần thì merge chúng lại. Hoặc nếu cần, họ sẽ hỏi ý kiến lập trình viên check in trước đó. Một khi các thay đổi đã được tích hợp, họ build lại hệ thống. Họ chạy lại tất cả các test trong hệ thống, bao gồm cả acceptance test. Nếu họ làm hỏng bất cứ thứ gì, họ phải sửa ngay. Nếu các test đều thành công, khi này họ mới được gọi là hoàn thành xong một check in. Như vậy nhóm XP sẽ build hệ thống nhiều lần trong ngày. Họ build toàn hệ thống từ đầu đến cuối. Nếu kết quả cuối cùng của hệ thống là 1 CD thì họ sẽ tạo một CD. Nếu kết quả của hệ thống là 1 web site,, họ sẽ cài đặt web site đó, có thể là trên 1 web server dành riêng cho test.

Chạy bền (Sustainable Pace) Một dư án phần mềm không phải là một cuộc chạy nước rút, mà nó là một cuộc chạy marathon. Nhóm nào vừa rời vạch xuất phát đã chạy thât nhanh thì sẽ tiêu tốn hết năng lượng trước khi họ về đến đích. Để hoàn tất được nhanh thì team càng phải kiểm soát được tốc độ, họ phải duy trì năng lượng và sự tỉnh táo. Họ phải chạy với nhịp độ vừa phải và vững chắc. Qui luật của XP là nhóm không được phép làm việc quá giờ (overtime). Ngoại lệ duy nhất là vào tuần cuối cùng của một phiên bản phát hành. Nếu team đang phải trong tình huống hoàn tất nhanh chóng kịp tiến độ phát hành thì có thể overtime.

17


Kết luận

Với lượng kiến thức vô cùng hạn chế cũng như chưa có nhiều thời gian để tìm hiểu chuyên sâu, báo cáo này không hy vọng mang đến những gì mới mẻ mà đơn giản chỉ là sự tổng hợp, lược dịch và chỉnh sửa lại các bài viết đã có trên internet, sách in và một số tài liệu khác. Sai sót về mặt nội dung cũng như khiếm khuyết trong cách trình bày chắc chắn không thể tránh khỏi, rất mong nhận được sự thông cảm và giúp đỡ của thầy để báo cáo được hoàn thiện hơn!

Em xin chân thành cám ơn!

18


Tài liệu tham khảo

What Is a Programming Paradigm? - Troy Holmes.

http:// wikipedia.com

http://congdongcviet.com

và một số trang web khác có liên quan!

19

Documents

một số mô thức lập trình