Tài liệu công nghệ phần mềm

Chia sẻ: Nguyen Quang Long | Ngày: | Loại File: DOC | Số trang:9

Thêm vào BST

Báo xấu

778
lượt xem 253
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Trong mô hình này, quá trình phát triển phần mềm được coi như một dòng chảy trải qua các pha yêu cầu, phân tích, thiết kế, cài đặt, tích hợp và bảo trì. Có tính lặp của từng pha, nghĩa là nếu trong một pha người ta phát hiện ra điều gì đó sai sót hoặc không phù hợp thì sẽ quay lại hiệu chỉnh ở pha trước.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Tài liệu công nghệ phần mềm

Câu 1: Trình bày nội dung vẽ sơ đồ, đánh giá ưu nhược điểm của các mô hình phát triền phần mềm sau a. Thác nước b. Bản mẫu nhanh c. Xây dựng và hiệu chỉnh d. Tăng dần Trả lời a. Mô hình thác nước Trong mô hình này, quá trình phát triển phần mềm được coi như một dòng chảy trải qua các pha yêu cầu, phân tích, thiết kế, cài đặt, tích hợp và bảo trì. Có tính lặp của từng pha, nghĩa là nếu trong một pha người ta phát hiện ra điều gì đó sai sót hoặc không phù hợp thì sẽ quay lại hiệu chỉnh ở pha trước. Hình 3.2 là sơ đồ biểu diễn mô hình thác đổ. Xác định yêu cầu Thay đổi yêu cầu Phân tích Thiết kế Cài đặt Tích hợp Bảo trì Phát triển Bảo trì Thôi sử dụng Hình 3.2. Mô hình thác đổ (waterfall model) Mô hình thác đổ là mô hình cũ nhất và được sử dụng rộng rãi nhất trong công nghệ phần mềm. Tuy nhiên cũng có nhiều ý kiến chỉ trích và cho rằng mô hình này có một số nhược điểm như sau: • Các dự án trong thực tế hiếm khi tuân theo dòng chảy tuần tự mà mô hình đề nghị. Mặc dầu mô hình cho phép lặp, nhưng điều đó chỉ làm gián tiếp. Kết quả là những thay đổi có thể gây ra lẫn lộn khi nhóm phát triển làm việc. • Khách hàng thường khó phát biểu mọi yêu cầu một cách tường minh ngay từ đầu. Mô hình tuần tự tuyến tính đòi hỏi điều này và thường khó thích hợp với sự không chắc chắn tự nhiên tồn tại vào lúc đầu của nhiều dự án. Khách hàng phải kiên nhẫn chờ đợi, vì bản làm việc được của chương tình chỉ có được vào cuối của thời gian dự án. Một sai lầm ngớ ngẩn, nếu đến lúc có chương trình làm việc mới phát hiện ra, có thể là một thảm họa. • Với việc phân tích một số dự án hiện tại, Bradax thấy rằng bản chất tuyến tính của vòng đời cổ điển dẫn tới "các trạng thái tắc nghẽn", nghĩa là có một số thành viên của nhóm phát triển phải chờ đợi sự chuyển giao từ nhóm khác hoàn thành công việc ở pha trước. Trong thực tế, thời gian chờ đợi có thể vượt quá thời gian sản xuất. Trạng thái nghẽn có xu hướng xẩy ra vào thời gian đầu và cuối của quy trình phần mềm. b. Bản mẫu nhanh 1
Mô hình bản mẫu thực chất cũng là mô hình thác đổ, nhưng phần xác định yêu cầu được thay bằng bản mẫu. Mô hình này có thể biểu diễn bởi sơ đồ sau: Bản mẫu Thay đổi yêu cầu Phân tích Thiết kế Cài đặt Tích hợp Bảo trì Phát triển Bảo trì Thôi sử dụng Hình 3.3. Mô hình bản mẫu (rapid prototyping model) Cũng như mô hình thác đổ, các pha từ bản mẫu đến thiết kế đều có kiểm tra (verify), các pha cài đặt và tích hợp có kiểm thử (test). Thông thường khách hàng đã xác định được một tập các mục tiêu tổng quát cho phần mềm, nhưng còn chưa nhận diện được đầu vào, đầu ra, những cái cần xử lý. Trong các trường hợp khác người phát triển có thể không chắc về tính hiệu quả của thuật toán, việc thích nghi hệ điều hành hay dạng màn hình giao diện cần có. Trong trường hợp này và nhiều trường hợp khác, cách làm bản mẫu có thể đưa ra cách tiếp cận tốt nhất. Để làm bản mẫu, đầu tiên người ta thu thập yêu cầu khách hàng. Người phát triển và khách hàng cùng ngồi lại với nhau để xác định các mục tiêu tổng thể cho phần mềm, xác định xem yêu cầu nào đã rõ ràng, yêu cầu nào còn phải xác định thêm. Tiếp theo là việc "thiết kế nhanh". Thiết kế nhanh chỉ tập trung vào việc biểu diễn các khía cạnh của phần mềm thấy được đối với người dùng, ví dụ màn hình nhập dữ liệu, các chức năng tìm kiếm, truy xuất thông tin, các báo cáo. Người phát triển có thể kết hợp để thử nghiệm một thuật toán. Tuy nhiên mục đích chính là thể hiện được các yêu cầu của khách hàng trong phần mềm mà chưa để ý đến tính tối ưu, tốc độ, sự hợp lý... Thiết kế nhanh dẫn tới việc xây dựng một bản mẫu. Bản mẫu được giới thiệu với khách hàng và có thể để họ dùng thử và đánh giá, góp ý kiến. Trên cơ sở ý kiến khách, hàng người phát triển làm mịn dần bản mẫu cho đến khi khách hàng thấy vừa ý (chủ yếu là cái vào, cái ra, giao diện...). Căn cứ vào bản mẫu người phát triển cũng hiểu rõ hơn yêu cầu khách hàng, những yêu cầu về cấu hình, về các thuật toán, cấu trúc dữ liệu, ngôn ngữ lập trình phù hợp. Lắng nghe Xây dựng/hiệu chỉnh khách hàng bản mẫu Khách hàng chạy thử bản mẫu 2
Hình 3.4. Mô thức làm bản mẫu c. Xây dựng và hiệu chỉnh Trong mô hình này không có các pha phân tích thiết kế. Phần mềm được xây dựng như sau: người phát triển sau khi trao đổi với khách hàng sẽ viết phiên bản đầu tiên. Tiếp theo, phần mềm được chạy thử với sự quan sát của khách hàng và liên tục được hiệu chỉnh cho đến khi khách hàng vừa ý (tức là đáp ứng được yêu cầu của khách hàng). Sau khi được khách hàng chấp nhận, phần mềm được đưa vào sử dụng và bảo trì. Mô hình này có thể biểu diễn trong sơ đồ sau: Xây dựng phiên bản đầu tiên Hiệu chỉnh cho đến khi khách hàng chấp nhận Sử dụng và bảo trì Phát triển Bảo trì Thôi sử dụng Hình 3.1. Mô hình xây dựng-và-hiệu chỉnh Khi viết chương trình thì người phát triển cũng phải hình dung ra các chức năng của phần mềm, những module phải có, những thuật toán sử dụng... Nghĩa là phần nào đó họ cũng có phân tích thiết kế, nhưng họ không biên soạn lại thành tài liệu mà thôi. Sau khi viết phiên bản đầu tiên, người phát triển đã hiểu khá rõ yêu cầu của khách hàng, họ cũng hiểu rõ các dòng lệnh vừa viết. Vì vậy khi khách hàng nêu yêu cầu hiệu chỉnh phần mềm thì họ biết ngay cần phải hiệu chỉnh phần nào của chương trình. Công việc thường được thực hiện khá nhanh chóng và phần mềm sớm được hoàn thành và đưa vào sử dụng. Nhược điểm của mô hình thể hiện rõ trong giai đoạn bảo trì. Công việc bảo trì thường là sửa lỗi và cập nhật. Nếu phần mềm vừa mới được đưa vào sử dụng và tác giả vẫn còn chịu trách nhiệm công việc này thì không có vấn đề gì lắm. Tuy nhiên nếu phần mềm đã được sử dụng sau một thời gian dài, khiến cho chính người viết chương trình cũng quên đi ý nghĩa các dòng lệnh; hoặc việc bảo trì lại do một người khác thực hiện thì sẽ rất khó khăn. Nếu bạn thử đọc chương trình nguồn của một tác giả khác mà không có tài liệu giải thích kèm theo thì bạn sẽ thấy rất khó hiểu. Rõ ràng mô hình xây dựng-và-hiệu chỉnh chỉ thích nghi cho phần mềm nhỏ, một người viết và ít khả năng phải sửa đổi trong quá trình sử dụng. d. Tăng dần Phần mềm được xây dựng từng bước, cũng như xây một ngôi nhà vậy. Nếu như khi xây dựng ngôi nhà có lúc người ta phải phá đi xây lại một bức tường không vừa ý thì khi làm phần mềm chúng ta cũng có thể sửa đổi thậm chí bỏ đi những module chương trình không phù hợp...Một phần mềm ra đời, được đưa vào sử dụng. Trong quá trình sử dụng ngoài việc phát hiện và sửa chữa sai sót, người ta thấy cần nâng cấp chất lượng bằng cách cải tiến một vài thuật toán, thêm một số chức năng. Trong mô hình tăng dần, người ta xem phần mềm bao gồm nhiều thành phần (build) tương đối độc lập nhau. Với hệ điều hành chẳng hạn, đó là thành phần scheduler, thành phần file management system,.. Mỗi thành phần như vậy được coi như một phần mềm nhỏ, được thiết kế, lập trình, kiểm thử và đưa cho khách hàng sử dụng theo mô hình thác đổ rồi kết hợp dần thành phần mềm hoàn 3
chỉnh thỏa mãn tất cả các yêu cầu của khách hàng. Ban đầu người ta chưa chú ý đến toàn bộ các yêu cầu của phần mềm mà chỉ chú ý đến những nét đặc trưng nhất và xây dựng phiên bản đầu tiên của phần mềm bao gồm các đặc trưng này rồi đưa cho khách hàng sử dụng. Chương trình được hiệu chỉnh theo ý kiến phản hồi của khách hàng. Tiếp theo người ta lại xây dựng phần mềm thứ hai thỏa mãn các đặc trưng quan trọng thứ hai và lại đưa cho khách hàng sử dụng và có ý kiến. Phần mềm thứ hai này sau khi hiệu chỉnh lại được tích hợp vào phần mềm đầu tiên thành một phần mềm lớn hơn. Phần mềm tích hợp này lại được kiểm thử để bảo đảm việc ghép nối thành công và chương trình chạy tốt. Cứ như vậy, thay vì xây dựng phần mềm hoàn chỉnh, người ta xây dựng các phần mềm con rồi tích hợp dần cho tới khi đạt được sản phẩm mong muốn. Sơ đồ sau mô tả mô hình tăng dần. Xác định yêu cầu Phân tích Thiết kế kiến trúc Với mỗi build thực hiện: Thiết kế chi tiết, lập trình, tích hợp, kiểm thử rồi chuyển giao cho khách hàng Phát triển Bảo trì Bảo trì Thôi sử dụng Hình 3.5. Mô hình tăng dần (incremental model) Nhận xét mô hình tăng dần Với mô hình thác đổ hoặc bản mẫu, sản phẩm được chuyển giao cho khách hàng chính là phiên bản hoàn chỉnh thỏa mãn tất cả các yêu cầu của khách hàng và có thể sử dụng ngay. Thời gian hoàn thành phần mềm được quy định trong hợp đồng và có thể sớm hoặc muộn hơn. Với mô hình tăng dần thì phần mềm được chia ra nhiều phần (thường là từ 5 đến 25 phần). Phần đầu tiên chứa đựng những đặc trưng quan trọng nhất được nhanh chóng xây dựng và chuyển giao cho khách hàng sử dụng. Thời gian hoàn thành phần đầu tiên này thường rất ngắn so với thời gian xây dựng toàn bộ phần mềm hoàn chỉnh. Như vậy khách hàng được sử dụng sản phẩm trong thời gian ngắn nhất và họ có thể được hưởng lợi từ việc sử dụng phần mềm. Khi mỗi phần sau được hoàn thành và được tích hợp thì họ được sử dụng ngay. Như vậy họ được làm quen từng bước với sản phẩm và sẽ ít bỡ ngỡ khi sản phẩm chứa đựng những công nghệ mới. Nhờ theo sát từng bước phát triển của phần mềm mà khách hàng có thể có những ý kiến xác đáng, giúp cho nhà phát triển đi đúng hướng và sản phẩm cuối cùng sẽ thỏa mãn được các yêu cầu đặt ra, thậm chí qua việc sử dụng một số phần đầu, khách hàng nhận thấy rằng không nên phát triển tiếp vì sẽ không mang lại lợi ích kinh tế. Khó khăn trong việc sử dụng mô hình tăng dần chính là sự tích hợp phần mới phát triển với phần chương trình đã có. Thiết kế của mô hình này do vậy phải có tính mở và tính mềm dẻo để thích nghi với việc mở rộng dần. Ta có thể nhận thấy rằng, trong mô hình tăng dần không có sự khác biệt giữa sự phát triển phần mềm và bảo trì cập nhật (nâng cao). Nếu vận dụng không hợp lý, mô hình này có thể suy thoái thành mô hình xây dựng-và-hiệu chỉnh. Sự điều khiển toàn bộ quy trình phát triển 4
phần mềm có thể bị mất và sản phẩm nhận được thay vì có tính mở lại là nỗi kinh hoàng cho những người bảo trì. Để tránh được điều này, người phát triển ngay từ đầu phải có cách nhìn toàn cục về sản phẩm, phải đưa ra thiết kế tổng thể của sản phẩm và sự phân chia các thành phần để phát triển sau này cũng phải trên cơ sở thiết kế toàn cục đó. Như sơ đồ 3.5. chỉ ra, các pha yêu cầu, đặc tả và thiết kế kiến trúc phải được thực hiện trước khi các thành phần nhỏ hơn được bắt đầu xây dựng. Nếu không có những nhà chuyên môn trình độ cao thì sản phẩm phát triển theo mô hình này có thể trở thành sản phẩm kém chất lượng. Câu 2: Phân biệt các yêu cầu chức năng và phi chức năng của phần mềm, nêu ví dụ minh họa Trả lời Yêu cầu chức năng thường gắn với chức năng tương ứng của phần mềm cần xây dựng và thể hiện dưới dạng các mục chọn của thực đơn, ví dụ như: "Phần mềm cung cấp chức năng tìm kiếm hàng hóa theo tên hàng và ngày bán". Đặc tả phi chức năng dùng để chỉ rõ tính chất nào đó của phần mềm cần xây dựng, ví dụ tính tin cậy và bảo trì được; hoặc liên quan đến môi trường mà phần mềm được sử dụng, ví dụ: tất cả các mã khách hàng được nhập trực tiếp từ bàn phím và được lưu trong một tệp bảng dữ liệu". Tóm lại yêu cầu chức năng là nói đến một công việc cụ thể, thường thể hiện bằng các mục chọn trong chương trình; còn yêu cầu phi chức năng thì nói về các tính chất của phần mềm, các tính chất này không thể thể hiện được bằng một việc cụ thể. Thí dụ từ câu "yêu cầu phần mềm phải có giao diện đẹp, thân thiện với người sử dụng" ta không thể nói được cụ thể là phải làm gì. Câu 3: Trình bày các phương pháp kiểm thử phần mềm Loại được đóng gói bán ra thị trường: Kiểm thử toàn bộ sản phẩm (product testing). Mục đích của việc kiểm thử này là bảo đảm rằng sản phẩm không có lỗi. Khi việc kiểm thử hoàn tất thì sản phẩm được chuyển qua giai đoạn kiểm thử alpha và beta. Nghĩa là phiên bản ban đầu được đưa cho một số khách hàng tương lai để họ sử dụng, Những thông tin phản hồi từ khách hàng được nhóm SQA xem xét và sản phẩm lại được hiệu chỉnh bởi nhóm phát triển nếu có lỗi được phát hiện. Loại làm theo hợp đồng cho một khách hàng: Đối với phần mềm đặt hàng (custom software) thì cách thức kiểm thử toàn bộ sản phẩm có khác chút ít. Nhóm SQA tiến hành một số kiểm thử để bảo đảm rằng sản phẩm có thể vượt qua được giai đoạn kiểm thử chấp nhận (acceptance test), tức là giai đoạn mà chương trình được cài đặt trên máy khách hàng, chạy với cấu hình và số liệu thực và được kiểm tra bởi khách hàng. Kiểm thử chấp nhận chính là rào cản cuối cùng mà nhóm phát triển phải vượt qua. Việc kiểm thử trước khi chuyển cho khách hàng kiểm tra là vô cùng quan trọng, do đó phải được thực hiện một cách thân trọng qua các bước như sau: 1. Thực hiện phép thử hộp đen cho toàn bộ sản phẩm. Trong quá trình tích hợp các module, ta mới chỉ kiểm thử xem từng module có thỏa mãn đặc tả không và phần mềm sau từng bước lắp ghép có hoạt động tốt không. Sản phẩm sau khi được tạo ra phải được kiểm thử một cách toàn diện. Kiểm thử hộp đen có nghĩa là kiểm tra xem chương trình chạy tốt không, tính toán cho kết quả chính xác không, nghĩa là ta chỉ quan tâm đến phần bên ngoài của phần mềm. Phần cấu trúc bên trong bị hộp đen (black-box) che khuất. (Hộp đen ở đây được dùng với ý nghĩa là không chú ý đến bên trong). 2. Cần kiểm thử tính ổn định (robustness) của sản phẩm một cách toàn cục. Tính ổn định của các module và từng phần của phần mềm đã được kiểm thử trong quá trình tích hợp. Khi quá trình tích hợp kết thúc thì phải kiểm thử tính ổn định của phần mềm một cách toàn cục. Cần có các trường hợp mẫu khác nhau để thử tính ổn định. Đặc biệt chú ý các kiểm thử cực điểm (stress 5
testing) , tức là kiểm thử được thực hiện khi phần mềm hoạt động ở mức tối đa, ví dụ tất cả các màn hình làm việc (terminal) đều được sử dụng, hay như với phần mềm điều khiển máy rút tiền thì tất cả các máy rút tiền đều được khách hàng sử dụng... Hay kiểm thử dung lượng (volume testing), ví dụ phần mềm có khả năng xử lý tệp dữ liệu đầu vào lớn không... 3. Nhóm SQA cần kiểm tra xem phần mềm đã thỏa mãn tất cả các ràng buộc nêu ra trong bản đặc tả hay chưa. Ví dụ, nếu bản đặc tả nói rằng khi chương trình đang làm việc ở mức tối đa (working under full load) thì 95% các yêu cầu truy xuất thông tin được trả lời trong vòng 3 giây chẳng hạn, thì nhóm SQA phải kiểm thử xem có đúng như vậy không. Ngoài ra, cần kiểm tra những ràng buộc về khả năng lưu trữ dữ liệu và tính bảo mật (storage constraints and security constraints). 4. Nhóm SQA cần xem xét lại tất cả tài liệu và chương trình cần chuyển giao cho khách hàng, có đối chiếu với bản kế hoạch quản lý dự án phần mềm. Kiểm tra các tài liệu có phù hợp với phần mềm không. Ví dụ xem lại tài liệu sử dụng và thử dùng nó để thao tác phần mềm xem phần mềm hoạt động đúng như tài liệu mô tả không. Câu 4: Trình bày các phương pháp cài đặt và tích hợp phần mềm từ trên xuống và từ dưới lên. Cài đặt và tích hợp từ trên xuống (top-down) Trong phương pháp cài đặt và tích hợp theo kiểu trên xuống (top-down implementation and integration), nếu module A có lời gọi đến module B thì A được cài đặt và kiểm thử trước B. Để kiểm thử A thì B cần được cài đặt dưới dạng stub. Sau khi A được kiểm thử thì cài đặt stub của B được mở rộng thành cài đặt thực sự... Cài đặt và tích hợp từ dưới lên (bottom-up) Phương pháp cài đặt và tích hợp theo kiểu dưới lên (bottom-up) được thực hiện ngược lại với phương pháp trên xuống. Đầu tiên các module ở mức dưới cùng (hay đôi khi còn gọi là mức cao nhất nếu nói về chiều cao của cây) được cài đặt và kiểm thử. Sau đó là các module ở mức phía trên được cài đặt và kiểm thử cùng với các module ở mức dưới. Cứ như vậy cho đến khi các module ở mức trên cùng được cài đặt và kiểm thử thì quá trình hoàn tất. Có thể thấy rằng phương pháp bottom-up có ưu điểm hơn phương pháp top-down ở chỗ là không phải tạo cài đặt dạng stub (các module ở tầng dưới cùng thường phải thử với các driver). Tuy nhiên nó cũng có một nhược điểm khá lớn là: nếu lỗi phát hiện ra muộn, tức là ở các mức ở gần gốc của cây chẳng hạn, lúc đó toàn bộ phần dưới của cây phải xem xét lại. Câu 5: Trình bày các công việc chính khi bảo trì một phần mềm Sau khi sản phẩm trải qua kiểm thử chấp nhận và thành công, phần mềm sẽ được huyển giao cho khách hàng. Thực ra, khi thực hiện kiểm thử chấp nhận thì phần mềm cũng được cài đặt trên máy tính của khách hàng, nhưng chỉ với mục đích kiểm thử. Trong quá trình này nếu phát hiện lỗi thì nhóm phát triển lại hiệu chỉnh phần mềm. Còn sự chuyển giao sau khi hoàn tất giai đoạn kiểm thử là sự chuyển giao chính thức theo hợp đồng. Sau đó phần mềm sẽ được khách hàng sử dụng vào công việc mà họ đặt ra ban đầu khi đặt hàng xây dựng phần mềm. Nhiều người nghĩ rằng vai trò của nhóm phát triển đến đây kết thúc, vì phần mềm đã hoàn tất. Tuy nhiên, mọi phần mềm có ích hầu như chắc chắn chuyển qua một giai đoạn hiệu chỉnh mà người ta gọi là pha bảo trì. Công việc bảo trì được phân làm hai loại: bảo trì sửa lỗi (software repair), tức là sửa các lỗi phát sinh mà trong giai đoạn kiểm thử chưa phát hiện ra. Cho dù việc kiểm thử có tiến hành cẩn thận và chi tiết đến đâu thì vẫn không thể khẳng định là phần mềm đã làm việc hoàn hảo. Vì con người dù rất thông minh cũng không thể hình dung trước được mọi tình huống. Loại bảo trì thứ hai là bảo trì cập nhật (software update). Bảo trì cập nhật lại bao gồm bảo trì hoàn thiện (perfective maintenance) và bảo trì thích nghi (adaptive maintenance). 6
Bởi vì ngoài các mã nguồn còn các tài liệu khác như hướng dẫn sử dụng, tài liệu phân tích thiết kế,...nên mọi sự thay đổi hiệu chỉnh trong các phần này đều được gọi là bảo trì. Câu 6: So sánh hai phương pháp phát triển phần mềm hướng đối tượng và hướng chức năng. Phương pháp hướng cấu trúc Đặc trưng của phương pháp hướng cấu trúc là phân chia chương trình chính thành nhiều chương trình con, mỗi chương trình con nhằm đến thực hiện một công việc xác định. Trong phương pháp hướng cấu trúc, phần mềm được thiết kế dựa trên một trong hai hướng : hướng dữ liệu và hướng hành động. Cách tiếp cận hướng dữ liệu xây dựng phần mềm dựa trên việc phân rã phần mềm theo các chức năng cần đáp ứng và dữ liệu cho các chức năng đó. Cách tiếp cận hướng dữ liệu sẽ giúp cho những người phát triển hệ thống dễ dàng xây dựng ngân hàng dữ liệu. Cách tiếp cận hướng hành động lại tập trung phân tích hệ phần mềm dựa trên các hoạt động thực thi các chức năng của phần mềm đó. Cách thức thực hiện của phương pháp hướng cấu trúc là phương pháp thiết kế từ trên xuống (top-down). Phương pháp này tiến hành phân rã bài toán thành các bài toán nhỏ hơn, rồi tiếp tục phân rã các bài toán con cho đến khi nhận được các bài toán có thể cài đặt được ngay sử dụng các hàm của ngôn ngữ lập trình hướng cấu trúc. Phương pháp hướng cấu trúc có ưu điểm là tư duy phân tích thiết kế rõ ràng, chương trình sáng sủa dễ hiểu. Tuy nhiên, phương pháp này có một số nhược điểm sau: Không hỗ trợ việc sử dụng lại. Các chương trình hướng cấu trúc phụ thuộc chặt chẽ vào cấu trúc dữ liệu và bài toán cụ thể, do đó không thể dùng lại một modul nào đó trong phần mềm này cho phần mềm mới với các yêu cầu về dữ liệu khác. Không phù hợp cho phát triển các phần mềm lớn. Nếu hệ thống thông tin lớn, việc phân ra thành các bài toán con cũng như phân các bài toán con thành các modul và quản lý mối quan hệ giữa các modul đó sẽ là không phải là dễ dàng và dễ gây ra các lỗi trong phân tích và thiết kế hệ thống, cũng như khó kiểm thử và bảo trì. Phương pháp hướng đối tượng Khác với phương pháp hướng cấu trúc chỉ tập trung hoặc vào dữ liệu hoặc vào hành động, phương pháp hướng đối tượng tập trung vào cả hai khía cạnh của hệ thống là dữ liệu và hành động. Cách tiếp cận hướng đối tượng là một lối tư duy theo cách ánh xạ các thành phần trong bài toán vào các đối tượng ngoài đời thực. Với cách tiếp cận này, một hệ thống được chia tương 7
ứng thành các thành phần nhỏ gọi là các đối tượng, mỗi đối tượng bao gồm đầy đủ cả dữ liệu và hành động liên quan đến đối tượng đó. Các đối tượng trong một hệ thống tương đối độc lập với nhau và phần mềm sẽ được xây dựng bằng cách kết hợp các đối tượng đó lại với nhau thông qua các mối quan hệ và tương tác giữa chúng. Các nguyên tắc cơ bản của phương pháp hướng đối tượng bao gồm : • Trừu tượng hóa (abstraction): trong phương pháp hướng đối tượng, các thực thể phần mềm được mô hình hóa dưới dạng các đối tượng. Các đối tượng này được trừu tượng hóa ở mức cao hơn dựa trên thuộc tính và phương thức mô tả đối tượng để tạo thành các lớp. Các lớp cũng sẽ được trừu tượng hóa ở mức cao hơn nữa để tạo thành một sơ đồ các lớp được kế thừa lẫn nhau. Trong phương pháp hướng đối tượng có thể tồn tại những lớp không có đối tượng tương ứng, gọi là lớp trừu tượng. Như vậy, nguyên tắc cơ bản để xây dựng các khái niệm trong hướng đối tượng là sự trừu tượng hóa theo các mức độ khác nhau. • Tính đóng gói (encapsulation) và ẩn dấu thông tin: các đối tượng có thể có những phương thức hoặc thuộc tính riêng (kiểu private) mà các đối tượng khác không thể sử dụng được. Dựa trên nguyên tắc ẩn giấu thông tin này, cài đặt của các đối tượng sẽ hoàn toàn độc lập với các đối tượng khác, các lớp độc lập với nhau và cao hơn nữa là cài đặt của hệ thống hoàn toàn độc lập với người sử dụng cũng như các hệ thống khác sử dụng kết quả của nó. • Tính modul hóa (modularity): các bài toán sẽ được phân chia thành những vấn đề nhỏ hơn, đơn giản và quản lý được. • Tính phân cấp (hierarchy): cấu trúc chung của một hệ thống hướng đối tượng là dạng phân cấp theo các mức độ trừu tượng từ cao đến thấp. Ưu điểm nổi bật của phương pháp hướng đối tượng là đã giải quyết được các vấn đề nảy sinh với phương pháp hướng cấu trúc: • Hỗ trợ sử dụng lại mã nguồn : Chương trình lập trình theo phương pháp hướng đối tượng thường được chia thành các gói là các nhóm của các lớp đối tượng khác nhau. Các gói này hoạt động tương đối độc lập và hoàn toàn có thể sử dụng lại trong các hệ thống thông tin tương tự. • Phù hợp với các hệ thống lớn: Phương pháp hướng đối tượng không chia bài toán thành các bài toán nhỏ mà tập trung vào việc xác định các đối tượng, dữ liệu và hành động gắn với đối tượng và mối quan hệ giữa các đối tượng. Các đối tượng hoạt động độc lập và chỉ thực hiện hành động khi nhận được yêu cầu từ các đối tượng khác. Vì vậy, phương pháp này hỗ trợ 8
phân tích, thiết kế và quản lý một hệ thống lớn, có thể mô tả các hoạt động nghiệp vụ phức tạp bởi quá trình phân tích thiết kế không phụ thuộc vào số biến dữ liệu hay số lượng thao tác cần thực hiện mà chỉ quan tâm đến các đối tượng tồn tại trong hệ thống đó. 9