Giáo trình Ngôn ngữ mô hình hoá thống nhất UML

175 trang hapham 1190

Download

Bạn đang xem 20 trang mẫu của tài liệu "Giáo trình Ngôn ngữ mô hình hoá thống nhất UML", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

giao_trinh_ngon_ngu_mo_hinh_hoa_thong_nhat_uml.pdf

Nội dung text: Giáo trình Ngôn ngữ mô hình hoá thống nhất UML

Giáo trình Ngôn ngữ mô hình hoá thống nhất UML - 1 -
LỜI NÓI ĐẦU Nhiệm vụ của công nghệ thông tin nói chung, công nghệ phần mềm nói riêng là nghiên cứu các mô hình, phương pháp và công cụ để tạo ra những hệ thống phần mềm chất lượng cao nhằm đáp ứng được những nhu cầu thường xuyên thay đổi, ngày một phức tạp của thực tế. Nhiều hệ thống phần mềm đã được xây dựng theo các cách tiếp cận truyền thống tỏ ra lạc hậu, không đáp ứng được các yêu cầu của người sử dụng. Cách tiếp cận hướng đối tượng giúp chúng ta có được những công cụ, phương pháp mới, phù hợp để giải quyết những vấn đề nêu trên. Cách tiếp cận này rất phù hợp với cách quan sát và quan niệm của chúng ta về thế giới xung quanh và tạo ra những công cụ mới, hữu hiệu để phát triển các hệ thống có tính mở, dễ thay đổi theo yêu cầu của người sử dụng, đáp ứng được các tiêu chuẩn phần mềm chất lượng cao theo yêu cầu của nền công nghệ thông tin hiện đại. Giáo trình này trình bày cách sử dụng ngôn ngữ mô hình hoá thống nhất UML (Unified Modeling Language) để phân tích và thiết kế hệ thống theo cách tiếp cận hướng đối tượng. Cách tiếp cận hướng đối tượng đặt trọng tâm vào việc xây dựng lý thuyết cho các hệ thống tổng quát như là mô hình khái niệm cơ sở. Hệ thống được xem như là tập các thực thể tác động qua lại và trao đổi với nhau bằng các thông điệp để thực hiện những nhiệm vụ đặt ra. Các khái niệm mới của mô hình hệ thống hướng đối tượng và các bước thực hiện phân tích, thiết kế hướng đối tượng được mô tả, hướng dẫn thực hiện thông qua ngôn ngữ chuẩn UML cùng phần mềm công cụ hỗ trợ mô hình hoá Rational Rose. Giáo trình được biên soạn theo yêu cầu giảng dạy, học tập môn học “Phân tích, thiết kế hệ thống” của ngành Công nghệ thông tin và dựa vào kinh nghiệm giảng dạy môn học này qua nhiều năm của các tác giả trong các khoá đào tạo cao học, đại học tại các Đại học Khoa học Huế, Đại học Quốc gia Hà Nội, Đại học Bách khoa Hà Nội, Đại học Đà Nẵng, Đại học Thái Nguyên, v.v. Giáo trình được trình bày trong tám chương. Chương mở đầu giới thiệu những khái niệm cơ sở trong mô hình hoá hệ thống và hai cách tiếp cận chính để phát triển các hệ thống phần mềm hiện nay là hướng thủ tục (chức năng) và hướng đối tượng. Chương II giới thiệu ngôn ngữ mô hình hoá thống nhất UML và vai trò của nó trong quá trình phát triển phần mềm. Vấn đề phân tích các yêu cầu của hệ thống và cách xây dựng biểu đồ ca sử dụng được nêu ở chương III. Chương IV trình bày những khái niệm cơ bản về các lớp đối tượng và các mối quan hệ của chúng trong không gian bài toán. Biểu đồ lớp cho phép biểu diễn tất cả những khái niệm đó một cách trực quan và thông qua mô hình khái niệm là biểu đồ lớp, chúng ta hiểu rõ hơn về hệ thống cần phát triển. Những biểu đồ tương tác thể hiện các hành vi và ứng xử của hệ thống được giới thiệu ở chương V. Dựa vào những kết quả phân tích ở các chương trước, hai chương tiếp theo nêu cách thực hiện để thiết kế các biểu đồ cộng tác cho từng nhiệm vụ, từng ca sử dụng của hệ thống và từ đó có được những thiết kế lớp, biểu đồ lớp chi tiết thực - 2 -
hiện chính xác các nhiệm vụ được giao. Vấn đề quan trọng là lựa chọn kiến trúc cho hệ thống và khả năng ánh xạ những kết quả thiết kế sang mã chương trình trong một ngôn ngữ lập trình hướng đối tượng như C++ được đề cập ở chương VII. Chương cuối trình bày một số vấn đề chính cần lưu ý khi thiết kế một CSDL HĐT, trong đó chủ yếu giới thiệu về việc ứng dụng ObjectStore trong cài đặt ứng dụng CSDL. Bài toán “Hệ thống quản lý bán hàng” được chọn làm ví dụ minh hoạ để phân tích, thiết kế hệ thống phần mềm theo cách tiếp cận hướng đối tượng xuyên suốt cả giáo trình. Tác giả xin chân thành cám ơn các bạn đồng nghiệp trong Viện CNTT, các bạn trong Khoa CNTT, Đại học Hue, các bạn trong Khoa Công nghệ, Đại học Quốc gia Hà Nội về những đóng góp quí báu, hỗ trợ thiết thực và động viên chân thành để hoàn thành cuốn giáo trình này. Mặc dù đã rất cố gắng nhưng giáo trình này chắc không tránh khỏi những sai sót. Chúng tôi rất mong nhận được các ý kiến góp ý của các thầy cô, những nhận xét của sinh viên và các bạn đọc để hiệu chỉnh thành cuốn sách hoàn thiện. Hà Nội 2004 Các tác giả - 3 -
CHƯƠNG I PHẦN MỀM VÀ MÔ HÌNH HOÁ HỆ THỐNG Chương I trình bày các vấn đề cơ sở về:  Các khái niệm và đặc trưng cơ bản của hệ thống phần mềm,  Vai trò của mô hình hoá hệ thống,  Các phương pháp phân tích và thiết kế hệ thống. 1.1 Giới thiệu về hệ thống phần mềm Hệ thống phần mềm hay gọi tắt là hệ thống, là tổ hợp các phần cứng, phần mềm có quan hệ qua lại với nhau, cùng hoạt động hướng tới mục tiêu chung thông qua việc nhận các dữ liệu đầu vào (Input) và sản sinh ra những kết quả đầu ra (Output) thường là ở các dạng thông tin khác nhau nhờ một quá trình xử lý, biến đổi có tổ chức. Một cách hình thức hơn chúng ta có thể định nghĩa phần mềm [3] bao gồm các thành phần cơ bản như sau: 1. Hệ thống các lệnh (chương trình) khi thực hiện thì tạo ra được các hoạt động và cho các kết quả theo yêu cầu, 2. Các cấu trúc dữ liệu làm cho chương trình thực hiện được các thao tác, xử lý và cho ra các thông tin cần thiết, 3. Các tài liệu mô tả thao tác và cách sử dụng chương trình. Có nhiều định nghĩa khác nhau về các hệ thống thông tin ([3], [4], [6]). Để hiểu hơn về bản chất của hệ thống thì tốt nhất là phải xem xét các đặc trưng cơ bản của chúng. Hệ thống thông tin cũng giống như các hệ thống khác đều có những đặc trưng cơ bản như sau: 1. Tính nhất thể hoá được thể hiện thông qua: . Phạm vi và qui mô của hệ thống được xác định như một thể thống nhất và không thay đổi trong những điều kiện nhất định. . Tạo ra những đặc tính chung để thực hiện được các nhiệm vụ hay nhằm đạt được các mục tiêu chung mà từng bộ phận riêng lẻ không thể thực hiện được. 2. Tính tổ chức có thứ bậc: . Mọi hệ thống luôn là hệ thống con của một hệ thống lớn hơn trong môi trường nào đó và chính nó lại bao gồm các hệ thống (các thành phần) nhỏ hơn. - 4 -
. Giữa các thành phần của một hệ thống có sự sắp xếp theo quan hệ thứ bậc hay một trình tự nhất định. . Tính có cấu trúc: Chính cấu trúc của hệ thống quyết định cơ chế vận hành của hệ thống và mục tiêu mà nó cần đạt được. Cấu trúc của hệ thống được thể hiện bởi:  Các phần tử được sắp xếp theo trật tự và cấu thành hệ thống.  Mối quan hệ giữa các thành phần liên quan chủ yếu đến loại hình, số lượng, chiều, cường độ, v.v. Những hệ thống có cấu trúc chặt thường được gọi là hệ thống có cấu trúc. Cấu trúc của hệ thống là quan trọng, nó có thể quyết định tính chất cơ bản của hệ thống. Ví dụ: Kim cương và than đá đều được cấu tạo từ các phân tử các-bon, nhưng khác nhau về cấu trúc nên: kim cương vô cùng rắn chắc, còn tham đá thì không có tính chất đó. Sự thay đổi cấu trúc có thể tạo ra những đặc tính mới (sức trồi mới, hay còn gọi là những đột biến) của hệ thống và khi vượt quá một ngưỡng nào đó thì có thể dẫn tới việc phá vỡ hệ thống cũ. Ví dụ: công nghệ biến đổi gen chủ yếu là làm thay đổi cấu trúc của các tế bào sinh học. 3. Tính biến đổi theo thời gian và không gian . Các hệ thống phải luôn thay đổi cho phù hợp với điều kiện thực tế theo thời gian và không gian, nghĩa là muốn tồn tại và phát triển thì phải biến đổi cho phù hợp với môi trường xung quanh theo qui luật tiến hoá của tự nhiên (Darwin). Sự khác nhau chủ yếu là tốc độ và khả năng nhận biết được về sự thay đổi đó. . Mọi sự thay đổi luôn có mối liên hệ ngược (feedback) trong hệ thống và chịu sự tác động của qui luật “nhân - quả”. Hệ thống được đánh giá theo nhiều tiêu chí khác nhau ([3], [6], [12]) và chưa có một hệ thống tiêu chí chuẩn để đánh giá cho các sản phẩm phần mềm. Ở đây chúng ta chỉ quan tâm đến một số tính chất quan trọng nhất hiện nay của các sản phẩm phần mềm. Một sản phẩm của công nghệ phần mềm hiện nay, ngoài những tính chất chung của các hệ thống nêu trên thì phải có các tính chất sau: Tính tiện dụng: sản phẩm phải dễ sử dụng và tiện lợi cho người dùng, hỗ trợ để thực hiện các công việc tốt hơn. Muốn đạt được mục đích này thì phần mềm phải có giao diện thân thiện, phù hợp với người sử dụng và có đầy đủ các tài liệu mô tả, có sự hỗ trợ kịp thời. Khả năng bảo hành và duy trì hoạt động: Hệ thống phải có khả năng cập nhật, dễ thay đổi, có khả năng mở rộng để thực hiện được những yêu cầu thay đổi của khách hàng. Tính tin cậy: Tính tin cậy của phần mềm không chỉ thể hiện ở khả năng thực hiện đúng nhiệm đã được thiết kế và cả các khả năng đảm bảo an toàn, an ninh dữ liệu. Hệ thống phải thực hiện bình thường ngay cả khi có sự kiện bất thường xảy ra. - 5 -
Tính hiệu quả: Phần mềm không gây ra sự lãng phí các tài nguyên như bộ nhớ, bộ xử lý, các thiết bị ngoại vi, v.v. Hệ thống có thể được phân loại theo nhiều quan điểm khác nhau. Theo nguyên nhân xuất hiện: hệ thống tự nhiên, sẵn có trong tự nhiên và hệ thống nhân tạo, do con người tạo ra. Theo quan hệ với môi trường: hệ đóng, ít trao đổi với môi trường xung quanh và hệ mở, có trao đổi và có thể thích ứng với các sự kiện xung quanh. Theo qui mô: lớn, trung bình và nhỏ. Theo sự thay đổi trạng thái trong không gian, thời gian: hệ động và hệ tĩnh, v.v. Người ta còn phân loại các hệ thống phần mềm theo các đặc tính chung của chúng. 1. Hệ thống thông tin: hệ thống lưu trữ, tìm kiếm, biến đổi và biểu diễn mọi thông tin cho người sử dụng. Khi khối lượng dữ liệu lớn, phức tạp thì hệ thống thường được tổ chức thành các hệ CSDL theo mô hình quan hệ hay hướng đối tượng. 2. Các hệ thống kỹ thuật: hệ thống xử lý và điều khiển các thiết bị kỹ thuật như các hệ viễn thông, các hệ thống quân sự, các quá trình công nghiệp, v.v. Đó thường là các hệ thống thời gian thực. 3. Các hệ thống nhúng thời gian thực: thực hiện trên những thiết bị cứng đơn giản và được nhúng vào các thiết bị khác như: mobile phone, hệ thống hướng dẫn lái xe ô tô, hệ thống điều khiển các dụng cụ dân dụng, v.v. 4. Các hệ thống phân tán: hệ thống được phân tán trên nhiều máy và dữ liệu được chuyển dễ dàng từ máy này sang máy khác. 5. Phần mềm hệ thống: Tạo ra các cơ sở (kiến trúc) cho các phần mềm khác sử dụng như: hệ điều hành, CSDL, giao diện phần mềm ứng dụng API (Application Programming Interface), v.v. 6. Các hệ thống nghiệp vụ: Mô tả mục đích, tài nguyên, các luật, chiến lược, sách lược hoạt động, kinh doanh và những công việc hiện thời trong các nghiệp vụ. Khi xây dựng một hệ thống chúng ta cần xác định xem nó thuộc loại hệ thống nào và mục tiêu chính của chúng ta là nghiên cứu hệ thống để: . Hiểu rõ hơn về chúng, nhất là những hệ thống lớn, phức tạp, để mô hình được chúng và từ đó xây dựng được những hệ thống phần mềm tốt. . Có thể tác động lên hệ thống một cách có hiệu quả. . Hoàn thiện hay phát triển những hệ thống tốt hơn nhằm đáp ứng mọi yêu cầu của khác hàng. Để xem xét sự phát triển hệ thống tin học, có hai khía cạnh cần đề cập: . Các phương pháp để nhận thức và diễn tả hệ thống, còn gọi là các mô hình. . Các bước nối tiếp trong thời kỳ phát triển hệ thống, còn gọi là chu kỳ phát triển hệ thống. - 6 -
1.2 Mô hình hoá hệ thống Các bước phát triển hệ thống như tìm hiểu nhu cầu, phân tích và thiết kế hệ thống tuy có khác nhau về nhiệm vụ, mục tiêu, song chúng có chung đặc điểm chung: phải đối đầu với sự phức tạp và những quá trình nhận thức, diễn tả sự phức tạp thông qua mô hình. Nói cách khác, để điều khiển được hệ thống hay phát triển được một hệ thống đáp ứng các yêu cầu, mục đích đặt ra thì phải thực hiện được mô hình hoá hệ thống. Thông qua mô hình chúng ta sẽ giới hạn vấn đề nghiên cứu bằng cách chỉ tập trung vào một khía cạnh trong phạm vi không gian và thời gian nhất định. Đó chính là nguyên lý chia để trị: tấn công vào những vấn đề khó bằng cách chia nó thành dãy các vấn đề nhỏ hơn mà ta có thể giải quyết được. Như Pascal đã khẳng: “Không thể hiểu toàn bộ mà không hiểu bộ phận và cũng không thể hiểu bộ phận mà không hiểu tổng thể”. Mô hình là một dạng trừu tượng hoá hệ thống thực của bài toán mà chúng ta đang xét, được diễn đạt một cách hình thức dễ hiểu bằng văn bản, biểu đồ, đồ thị, công thức hay phương trình toán học, v.v. Mục đích của mô hình hoá: 1. Mô hình giúp ta hiểu và thực hiện được sự trừu tượng, tổng quát hoá các khái niệm cơ sở để giảm thiểu độ phức tạp của hệ thống. Qua mô hình chúng ta biết được hệ thống gồm những gì? và chúng hoạt động như thế nào?. Jean Piaget [5] từng nói: “Hiểu tức là mô hình hoá”. Do vậy, quá trình phát triển phần mềm chẳng qua là quá trình nhận thức và mô tả lại tả hệ thống đó. Đó cũng là quá trình thiết lập, sử dụng và biến đổi các mô hình. Vậy, có một mô hình đúng sẽ giúp ta làm sáng tỏ những vấn đề phức tạp và cho ta cái nhìn thấu đáo về vấn đề cần giải quyết. 2. Mô hình giúp chúng ta quan sát được hệ thống như nó vốn có trong thực tế hoặc nó phải có như ta mong muốn. Muốn hiểu và phát triển được hệ thống phần mềm theo yêu cầu thực tế thì ta phải quan sát nó theo nhiều góc nhìn khác nhau: theo chức năng sử dụng, theo các thành phần logic, theo phương diện triển khai, v.v. 3. Mô hình cho phép ta đặc tả được cấu trúc và hành vi của hệ thống: + Đảm bảo hệ thống đạt được mục đích đã xác định trước. Mọi mô hình đều đơn giản hoá thế giới thực, nhưng phải đảm bảo sự đơn giản đó không loại bỏ đi những những yếu tố quan trọng. + Kiểm tra được các qui định về cú pháp, ngữ nghĩa về tính chặt chẽ và đầy đủ của mô hình, khẳng định được tính đúng đắn của thiết kế, phù hợp với yêu cầu của khách hàng. Nghĩa là, mô hình hoá là quá trình hoàn thiện và tiến hoá liên tục. 4. Mô hình hoá là nhằm tạo ra khuôn mẫu (template) và hướng dẫn cách xây dựng hệ thống; cho phép thử nghiệm, mô phỏng và thực hiện, hoàn thiện theo mô hình. 5. Mô hình là cơ sở để trao đổi, ghi lại những quyết định đã thực hiện trong nhóm tham gia dự án phát triển phần mềm. Mọi quan sát, mọi sự hiểu biết - 7 -
(kết quả phân tích) đều phải được ghi lại chi tiết để phục vụ cho cả quá trình phát triển hệ thống. Để tìm hiểu một thế giới vô cùng phức tạp, mọi khoa học thực nghiệm đều phải vận dụng một nguyên lý cơ bản, đó là sự trừu tượng hoá (Absstraction). Trừu tượng hoá là một nguyên lý của nhận thức, đòi hỏi phải bỏ qua những sắc thái (của chủ điểm) không liên quan tới chủ định hiện thời, để tập trung hoàn toàn vào các sắc thái chính liên quan tới chủ định đó (từ điểm Oxford). Nhìn chung không có mô hình nào là đầy đủ. Mỗi hệ thống thực tế có thể được tiếp cận thông qua một hay một số mô hình khác nhau. Quá trình mô hình hoá hệ thống phần mềm thường thực hiện theo hai cấp: + Mô hình logic: mô tả các thành phần và mối quan hệ của chúng để tổ chức thực hiện, về biện pháp cài đặt. Mô hình logic trả lời câu hỏi “Là gì?” và bỏ qua câu hỏi “như thế nào?”, + Mô hình vật lý: xác định kiến trúc các thành phần và tổng thể của hệ thống. Trả lời câu hỏi “Như thế nào?”, quan tâm tới biện pháp, công cụ, kế hoạch thực hiện. Tóm lại, mô hình hoá một hệ thống phải thực hiện theo cả bốn hướng: Kiến trúc (các thành phần) vật lý Các chức năng, nhiệm vụ hoặc quá Cấu trúc tĩnh (dữ liệu, trình xử lý các nhiệm thông tin được lưu trữ, vụ của hệ thống. xử lý và các yếu tố tạo nên hệ thống). Cách ứng xử (hành vi) Các phản ứng tức thời, các tiến hoá trong thời gian dài Hình 1-1 Các hướng mô hình hoá Hướng của điểm xuất phát sẽ kéo theo phương pháp cần lựa chọn để phát triển phần mềm. Nếu ta bắt đầu từ bên trái, nghĩa là tập trung vào chức năng để phân tích thì chúng ta thực hiện phát triển phần mềm theo cách tiếp cận hướng chức năng. Ngược lại, nếu bắt đầu từ bên phải, nghĩa là dựa vào dữ liệu là chính thì chúng ta sử dụng phương pháp hướng đối tượng. Có bốn yếu tố quan trọng ảnh hưởng tới hiệu quả của dự án phát triển phần mềm: Nhân tố ảnh hưởng Thuộc tính Sản phẩm phần mềm Mức độ tin cậy, chính xác của phần mềm yêu cầu Cỡ của CSDL, số lượng dữ liệu (bài toán ứng dụng) Độ phức tạp của sản phẩm phần mềm Những ràng buộc về thời gian thực hiện Máy tính (công nghệ) Những ràng buộc về bộ nhớ chính Tần xuất thay đổi của hệ điều hành và/hoặc phần cứng Môi trường phát triển chương trình Khả năng của các nhà phân tích, thiết kế Con người Kinh nghiệm làm việc với những hệ tương tự Khả năng của các lập trình viên Kinh nghiệm làm việc với hệ điều hành và/hoặc phần cứng Mức độ thông thạo ngôn ngữ lập trình được lựa chọn - 8 -
Qui trình Sử dụng phương pháp để phát triển phần mềm Sử dụng công cụ phát triển phần mềm Lịch biểu phát triển phần mềm Vấn đề rất quan trọng hiện nay trong công nghệ phần mềm là cần phải có những công cụ hỗ trợ để thực hiện mô hình hoá trực quan theo một chuẩn dễ hiểu giúp cho việc trao đổi giữa những người phát triển phần mềm hiệu quả và dễ dàng hơn. Các nhà tin học đã rất cố gắng để phát triển các công cụ thực hiện mô hình hoá trực quan. Từ những khái niệm, ký pháp quen thuộc của Booch, Ericsson, OOSE/Objectory (Jacobson), OMT (Rumbaugh) người ta đã xây dựng được một ngôn ngữ mô hình thống nhất UML được nhiều người chấp nhận và sử dụng như một ngôn ngữ chuẩn trong phân tích và thiết kế hệ thống phần mềm. Hầu hết các hãng sản xuất phần mềm lớn như: Microsoft, IBM, HP, Oracle, v.v đều sử dụng UML như là chuẩn công nghiệp. Trong tài liệu này chúng ta sử dụng UML để phân tích, thiết kế hệ thống. Chi tiết về UML và cách sử dụng nó để phân tích và thiết kế hệ thống sẽ được trình bày chi tiết ở các phần sau. 1.3 Các cách tiếp cận trong phát triển phần mềm Để thực hiện một dự án phát triển phần mềm thì vấn đề quan trọng đầu tiên chắc sẽ là phải chọn cho được một cách thực hiện thích hợp dựa trên những yếu tố nêu trên. Có hai cách tiếp cận cơ bản để phát triển phần mềm: cách tiếp hướng chức năng và cách tiếp cận hướng đối tượng. 1.3.1 Cách tiếp cận hướng chức năng Phần lớn các chương trình được viết bằng ngôn ngữ lập trình như C, hay Pascal từ trước đến nay đều được thực hiện theo cách tiếp cận hướng chức năng hay còn được gọi là cách tiếp cận hướng thủ tục. Cách tiếp cận này có những đặc trưng sau: 1. Dựa vào chức năng, nhiệm vụ là chính. Khi khảo sát, phân tích một hệ thống chúng ta thường tập trung vào các nhiệm vụ mà nó cần thực hiện. Chúng ta tập trung trước hết nghiên cứu các yêu cầu của bài toán để xác định các chức năng chính của hệ thống. Ví dụ khi cần xây dựng “hệ thống quản lý thư viện” thì trước hết chúng ta thường đi nghiên cứu, khảo sát trao đổi và phỏng vấn xem những người thủ thư, bạn đọc cần phải thực hiện những công việc gì để phục vụ được bạn đọc và quản lý tốt được các tài liệu. Qua nghiên cứu “hệ thống quản lý thư viện”, chúng ta xác định được các nhiệm vụ chính của hệ thống như: quản lý bạn đọc, cho mượn sách, nhận trả sách, thông báo nhắc trả sách, v.v. Như vậy, khi đã nghiên cứu để hiểu rõ được bài toán và xác định được các yêu cầu của hệ thống thì các chức năng, nhiệm vụ của hệ thống gần như là không thay đổi suốt trong quá trình phát triển tiếp theo ngoại trừ khi cần phải khảo sát lại bài toán. Dựa chính vào chức năng (thuật toán) thì dữ liệu sẽ là phụ và biến đổi theo các chức năng. Do đó, hệ thống phần mềm được xem như là tập các chức năng, nhiệm vụ cần tổ chức thực thi. 2. Phân rã chức năng và làm mịn dần theo cách từ trên xuống (Top/Down). Khả năng của con người là có giới hạn khi khảo sát, nghiên cứu để hiểu và thực thi - 9 -
những gì mà hệ thống thực tế đòi hỏi. Để thống trị (quản lý được) độ phức tạp của những vấn đề phức tạp trong thực tế thường chúng ta phải sử dụng nguyên lý chia để trị, nghĩa là phân tách nhỏ các chức năng chính thành các chức năng đơn giản hơn theo cách từ trên xuống. Quá trình này được lặp lại cho đến khi thu được những đơn thể chức năng tương đối đơn giản, hiểu được và thực hiện cài đặt chúng mà không làm tăng thêm độ phức tạp để liên kết chúng trong hệ thống. Độ phức tạp liên kết các thành phần chức năng của hệ thống thường là tỉ lệ nghịch với độ phức tạp của các đơn thể. Vì thế một vấn đề đặt ra là có cách nào để biết khi nào quá trình phân tách các đơn thể chức năng hay còn gọi là quá trình làm mịn dần này kết thúc. Thông thường thì quá trình thực hiện phân rã các chức năng của hệ thống phụ thuộc nhiều vào độ phức hợp của bài toán ứng dụng và vào trình độ của những người tham gia phát triển phần mềm. Một hệ thống được phân tích dựa trên các chức năng hoặc quá trình sẽ được chia thành các hệ thống con và tạo ra cấu trúc phân cấp các chức năng. Ví dụ, hệ thống quản lý thư viện có thể phân chia từ trên xuống như sau: Hệ thống quản lý thư viện Quản lý bạn đọc Cho mượn tài liệu Nhận trả tài liệu Nhắc trả tài liệu Hình 1-2 Sơ đồ chức năng của Hệ thống quản lý thư viện Chúng ta có thể khẳng định là các chức năng của nhiều hệ thống thông tin quản lý đều có thể tổ chức thành sơ đồ chức năng theo cấu trúc phân cấp có thứ bậc. 3. Các đơn thể chức năng trao đổi với nhau bằng cách truyền tham số hay sử dụng dữ liệu chung. Một hệ thống phần mềm bao giờ cũng phải được xem như là một thể thống nhất, do đó các đơn thể chức năng phải có quan hệ trao đổi thống tin, dữ liệu với nhau. Trong một chương trình gồm nhiều hàm (thực hiện nhiều chức năng khác nhau) muốn trao đổi dữ liệu được với nhau thì nhất thiết phải sử dụng dữ liệu liệu chung hoặc liên kết với nhau bằng cách truyền tham biến. Mỗi đơn thể chức năng không những chỉ thao tác, xử lý trên những biến dữ liệu cục bộ mà còn phải sử dụng các biến chung, thường đó là các biến toàn cục. Dữ liệu chung Dữ liệu chung Chức năng 1 Chức năng 2 Dữ liệu riêng Dữ liệu riêng Hình 1-3 Mối quan hệ giữa các chức năng trong hệ thống - 10 -
Với việc sử dụng những biến toàn cục thì những bất lợi trong quá trình thiết kế và lập trình là khó tránh khỏi. Đối với những dự án lớn, phức tạp có nhiều nhóm tham gia, mỗi nhóm chỉ đảm nhận một số chức năng nhất định và như thế khi một nhóm có yêu cầu thay đổi về dữ liệu chung đó thì sẽ kéo theo tất cả các nhóm khác có liên quan cũng phải thay đổi theo. Kết quả là khi có yêu cầu thay đổi của một đơn thể chức năng sẽ ảnh hưởng tới các chức năng khác và do đó sẽ ảnh hưởng tới hiệu xuất lao động của các nhóm cũng như của cả dự án. Mặt khác, các chức năng của hệ thống có nhu cầu phải thay đổi là tất yếu và rất thường xuyên. 4. Tính mở và thích nghi của hệ thống được xây dựng theo cách tiếp cận này là thấp vì: Hệ thống được xây dựng dựa vào chức năng là chính mà trong thực tế thì chức năng, nhiệm vụ của hệ thống lại hay thay đổi. Để đảm bảo cho hệ thống thực hiện được công việc theo yêu cầu, nhất là những yêu cầu về mặt chức năng đó lại bị thay đổi là công việc phức tạp và rất tốn kém. Ví dụ: giám đốc thư viện yêu cầu thay đổi cách quản lý bạn đọc hoặc hơn nữa, yêu cầu bổ sung chức năng theo dõi những tài liệu mới mà bạn đọc thường xuyên yêu cầu để đặt mua, v.v. Khi đó vấn đề duy trì hệ thống phần mềm không phải là vấn đề dễ thực hiện. Nhiều khi có những yêu cầu thay đổi cơ bản mà việc sửa đổi không hiệu quả và vì thế đòi hỏi phải thiết kế lại hệ thống thì hiệu quả hơn. Các bộ phận của hệ thống phải sử dụng biến toàn cục để trao đổi với nhau, do vậy khả năng thay đổi, mở rộng của chúng và của cả hệ thống là bị hạn chế. Như trên đã phân tích, những thay đổi liên quan đến các dữ liệu chung sẽ ảnh hưởng tới các bộ phận liên quan. Do đó, một thiết kế tốt phải rõ ràng, dễ hiểu và mọi sửa đổi chỉ có hiệu ứng cục bộ. 5. Khả năng tái sử dụng bị hạn chế và không hỗ cơ chế kế thừa. Để có độ thích nghi cao thì mỗi thành phần phải là tự chứa. Muốn là tự chứa hoàn toàn thì một thành phần không nên dùng các thành phần ngoại lai. Tuy nhiên, điều này lại mâu thuẫn với kinh nghiệm nói rằng các thành phần hiện có nên là dùng lại được. Vậy là cần có một sự cân bằng giữa tính ưu việt của sự dùng lại các thành phần (ở đây chủ yếu là các hàm) và sự mất mát tính thích ứng được của chúng. Các thành của hệ thống phải có tính cố kết nhưng phải tương đối lỏng để dễ thích nghi. Một trong cơ chế chính hỗ trợ để dễ có được tính thích nghi là kế thừa thì cách tiếp cận hướng chức năng lại không hỗ trợ. Đó là cơ chế biểu diễn tính tương tự của các thực thể, đơn giản hoá định nghĩa những khái niệm tương tự từ những sự vật đã được định nghĩa trước trên cơ sở bổ sung hay thay đổi một số các đặc trưng hay tính chất của chúng. Cơ chế này giúp chúng ta thực hiện được nguyên lý tổng quát hoá và chi tiết hoá các thành phần của hệ thống phần mềm. 1.3.2 Cách tiếp cận hướng đối tượng Để khắc phục được những vấn đề tồn tại nêu trên thì chúng ta cần phải nghiên cứu phương pháp, mô hình và công cụ mới, thích hợp cho việc phát triển phần mềm đáp ứng các yêu cầu của khách hàng. Mô hình hướng đối tượng ([1], [4], [9]) có thể giúp chúng ta vượt được khủng hoảng trong công nghệ phần mềm và hy vọng sẽ đưa - 11 -
ra được những sản phẩm phần mềm thương mại chất lượng cao: tin cậy, dễ mở rộng, dễ thích nghi, cường tráng và phù hợp với yêu cầu của khách hàng. Cách tiếp cận hướng đối tượng có những đặc trưng sau. 1. Đặt trọng tâm vào dữ liệu (thực thể). Khi khảo sát, phân tích một hệ thống chúng ta không tập trung vào các nhiệm vụ như trước đây mà tìm hiểu xem nó gồm những thực thể nào. Thực thể hay còn gọi là đối tượng, là những gì như người, vật, sự kiện, v.v. mà chúng ta đang quan tâm, hay cần phải xử lý. Ví dụ, khi xây dựng “Hệ thống quản lý thư viện” thì trước hết chúng ta tìm hiểu xem nó gồm những lớp đối tượng hoặc những khái niệm nào. 2. Xem hệ thống như là tập các thực thể, các đối tượng. Để hiểu rõ về hệ thống, chúng ta phân tách hệ thống thành các đơn thể đơn giản hơn. Quá trình này được lặp lại cho đến khi thu được những đơn thể tương đối đơn giản, dễ hiểu và thực hiện cài đặt chúng mà không làm tăng thêm độ phức tạp khi liên kết chúng trong hệ thống. Xét “Hệ thống quản lý thư viện”, chúng ta có các lớp đối tượng sau: Tập_Danh_Mục Sách Bạn_Đọc Tạp_Chí Hình 1-4 Tập các lớp đối tượng của hệ thống 3. Các lớp đối tượng trao đổi với nhau bằng các thông điệp. Theo nghĩa thông thường thì lớp là nhóm một số người, vật có những đặc tính tương tự nhau hoặc có những hành vi ứng xử giống nhau. Trong mô hình đối tượng, khái niệm lớp là cấu trúc mô tả hợp nhất các thuộc tính, hay dữ liệu thành phần thể hiện các đặc tính của mỗi đối tượng và các phương thức, hay hàm thành phần thao tác trên các dữ liệu riêng và là giao diện trao đổi với các đối tượng khác để xác định hành vi của chúng trong hệ thống. Khi có yêu cầu dữ liệu để thực hiện một nhiệm vụ nào đó, một đối tượng sẽ gửi một thông điệp (gọi một phương thức) cho đối tượng khác. Đối tượng nhận được thông điệp yêu cầu sẽ phải thực hiện một số công việc trên các dữ liệu mà nó sẵn có hoặc lại tiếp tục yêu cầu những đối tượng khác hỗ trợ để có những thông tin trả lời cho đối tượng yêu cầu. Với phương thức xử lý như thế thì một chương trình hướng đối tượng thực sự có thể không cần sử dụng biến toàn cục nữa. 4. Tính mở và thích nghi của hệ thống cao hơn vì: Hệ thống được xây dựng dựa vào các lớp đối tượng nên khi có yêu cầu thay đổi thì chỉ thay đổi những lớp đối tượng có liên quan hoặc bổ sung thêm một số lớp đối tượng mới (có thể kế thừa từ những lớp có trước) để thực thi những nhiệm vụ mới mà hệ thống cần thực hiện. Ví dụ: Giám đốc thư viện yêu cầu bổ sung chức năng theo dõi những tài liệu mới mà bạn đọc thường xuyên yêu cầu để đặt mua, ta có thể bổ sung thêm lớp mới để theo dõi yêu cầu: lớp Yêu_Cầu. Trong các chương trình hướng đối tượng có thể không cần sử dụng biến toàn cục nên mọi sửa đổi, cập nhật trong mỗi thành phần chỉ có hiệu ứng cục bộ. - 12 -
5. Hỗ trợ sử dụng lại và cơ chế kế thừa. Các lớp đối tượng được tổ chức theo nguyên lý bao gói và che giấu thông tin, điều này làm tăng thêm hiệu quả của kế thừa và độ tin cậy của hệ thống. Các ngôn ngữ lập trình hướng đối tượng như: C++, Java, C#, Delphi, v.v. đều hỗ trợ quan hệ kế thừa. Phát triển phần mềm hướng đối tượng Phát triển phần mềm có cấu trúc Phân tích Phân tích Bước đệm Thiết kế Lập trình hướng đối Thiết kế tượng Bước đệm Lập trình Lập trình có cấu trúc Lập trình CSDL Bước đệm CSDL hướng đối tượng CSDL CSDL quan hệ Hình 1-5 Hai phương pháp chính trong phát triển phần mềm 1.3.3 Ưu điểm chính của phương pháp hướng đối tượng Đối tượng là cơ sở để kết hợp các đơn thể có thể sử dụng lại thành hệ thống lớn hơn, tạo ra những sản phẩm có chất lượng cao. Qui ước truyền thông điệp giữa các đối tượng đảm bảo cho việc mô tả các giao diện giữa các đối tượng thành phần bên trong hệ thống và những hệ thống bên ngoài trở nên dễ dàng hơn. Điều đó giúp cho việc phân chia những dự án lớn, phức tạp để phân tích, thiết kế theo cách chia nhỏ bài toán thành các lớp đối tượng hoàn toàn tương ứng với quan điểm hướng tới lời giải phù hợp với thế giới thực một các tự nhiên. Nguyên lý bao gói, che giấu thông tin hỗ trợ cho việc xây dựng những hệ thống thông tin an toàn. - 13 -
Nguyên lý kế thừa dựa chính vào dữ liệu rất phù hợp với ngữ nghĩa của mô hình trong cài đặt. Lập trình hướng đối tượng đặc biệt là kỹ thuật kế thừa cho phép dễ dàng xác định các đơn thể và sử dụng ngay khi chúng chưa thực hiện đầy đủ các chức năg (đơn thể mở) và sau đó mở rộng được mà không làm ảnh hưởng tới các đơn thể khác. Định hướng đối tượng cung cấp những công cụ, môi trường mới, hiệu quả để phát triển phần mềm theo hướng công nghiệp và hỗ trợ để tận dụng được những khả năng kế thừa, sử dụng lại ở phạm vi diện rộng để xây dựng được những hệ thống phức tạp, nhạy cảm như: hệ thống động, hệ thống thời gian thực, v,v. Xoá bỏ được hố ngăn cách giữa các pha phân tích, thiết kế và cài đặt trong quá trình xây dựng phần mềm. Hình 1-5 mô tả sự giống và khác nhau của hai cách tiếp cận trong quá trình phát triển phần mềm. 1.4 Các mô hình chu trình phát triển phần mềm Có nhiều kiểu mô hình cho quá trình phát triển phần mềm. Ivan Sommerville [3] nói tới năm loại mô hình khác nhau. 1. Mô hình thác nước [12]: quá trình phần mềm được chia thành dãy các pha liên tiếp từ phân tích yêu cầu, phân tích, thiết kế hệ thống, lập trình đến thử nghiệm và triển khai hệ thống. Pha sau chỉ được bắt đầu khi pha trước đã hoàn thành. Mô hình này được thiết lập theo cách tiếp cận hướng chức năng và phù hợp cho những dự án lớn, phức tạp. Ưu điểm: + Thích hợp cho những dự án lớn. + Dự án thực hiện lần lượt theo các pha của một tiến trình nên việc quản lý dự án sẽ dễ dàng và thuận tiện. Nhược điểm: + Các yêu cầu của NSD (người sử dụng) không phản ánh, trao đổi được với nhóm phát triển cho đến khi hoàn tất từng giai đoạn phát triển. + Không cho phép thay đổi nhiều theo các đặc tả yêu cầu của hệ thống. 2. Mô hình thăm dò (hình xoán ốc): Phát triển càng nhanh càng tốt một hệ thống rồi cải tiến hệ thống đó cho tới khi nó đáp ứng được các yêu cầu của khách hàng. Các bước thực hiện cũng giống như mô hình thác nước nhưng luôn có xét tới các yếu tố khả thi, các sự cố tác động vào hệ thống, nghĩa là phân tích các yêu tố rủi ro và những yêu cầu mới, thay đổi của NSD nhằm tạo ra những phần mềm gần với những yêu cầu thực tế hơn. Theo Raccoon thì những năm gần đây người ta quan tâm nhiều hơn tới mô hình xoắn ốc được Boëhm đưa ra năm 1988. Phát triển phần mềm theo mô hình này dựa trên việc phân tích các rủi ro. Quá trình phát - 14 -
triển được chia thành nhiều thời kỳ, mỗi thời kỳ bắt đầu bằng việc phân tích, rồi tạo nguyên mẫu, các công đoạn để cải tạo, duyệt lại và cứ thế tiếp tục cho tới khi đạt được muc đích. Ưu điểm: + Linh hoạt hơn trong quá trình phát triển hệ thống cho thích hợp với những thay đổi trong đặc tả yêu cầu. Nhược điểm: + Các pha thực hiện bị lặp nhiều trong cả quá trình phát triển hệ thống. 3. Tạo nguyên mẫu: (gần như mô hình thăm dò) phát triển một hệ thống cho người dùng thử nghiệm, rồi thiết lập các yêu cầu và tạo ra nguyên mẫu mới cho tới khi sản phẩm đạt yêu cầu. NSD và những người phát triển hệ thống có thể trao đổi với nhau để thống nhất về những yêu cầu trong quá trình phát triển phần mềm. Ngày nay với công nghệ thế hệ thứ tư 4GT bao gồm nhiều cái mới như các ngôn ngữ khai báo, các gói chương trình ứng dụng, nhiều phần mềm giao diện rất mạnh, các công cụ trợ giúp CASE, v.v. Lợi dụng khả năng này, người ta nhanh chóng xây dựng một phương án thô để phát triển một nguyên mẫu rồi đem cho NSD dùng thử. Nếu phát hiện được chỗ NSD chưa bằng lòng, thì chỉnh sửa lại và hoàn thiện để có nguyên mẫu tiếp theo. Cứ thế thành lập một dãy các nguyên mẫu, rốt cuộc người ta đạt được hệ thống đáp ứng các yêu cầu NSD. Ưu điểm: + Cho phép xây dựng những hệ thống thực hiện hiệu quả các chức năng mà NSD yêu cầu. + Trong quá trình thực hiện cho phép kiểm tra các yêu cầu của NSD có cần thiết, có đáp ứng thực tế hay không, do vậy cho phép bổ sung kịp thời và đồng thời loại bỏ đi những điểm không cần thiết. + Các chức năng, hiệu xuất và khả năng thao tác của hệ thống có thể kiểm nghiệm trong quá trình phát triển hệ thống, do vậy tổng thời gian phát triển có thể sẽ được rút ngắn. Nhược điểm: + Không thích hợp cho những dự án lớn, chỉ thích hợp cho những dự án vừa và nhỏ. 4. Biến đổi hình thức: Phát triển một đặc tả hình thức cho một hệ thống và phân tích để biến đổi các đặc tả đó (đảm bảo tính đúng đắn của các phép biến đổi) cho tới khi có được một chương trình thoả mãn các yêu cầu. 5. Tập hợp các thành phần dùng lại được để xây dựng phần mềm thoả các yêu cầu. Việc tạo lập hệ thống được thực hiện bằng cách lắp ráp các thành phần có sẵn. Theo Hooper, Chester và Kang thì quá trình tập hợp các thành phần gồm 6 bước: nhận thức bài toán, hình thành giải pháp, tìm kiếm các thành phần, điều chỉnh và thích ứng các thành phần, tích hợp chúng và đánh giá hệ thống được tuyển chọn. Tóm lại, khuôn cảnh chung của kỹ nghệ phần mềm có thể được mô tả như sau: - 15 -
Tập hợp các yêu cầu Phân tích có Làm bản Phân tích Mô hình cấu trúc mẫu 1 hướng đối xoắn ốc tượng Thiết kế có . Thiết kế . cấu trúc . hướng đối . tượng Lập trình có Làm bản Lập trình Mẫu hình cấu trúc mẫu n hướng đối vòng thứ n tượng Lập trình hướng đối tượng Kiểm chứng Hệ thông hoạt động Bảo trì Hình 1- 6 Mô hình phát triển phần mềm Câu hỏi và bài tập 1.1 Hệ thống phần mềm là gì?, nếu các đặc trưng cơ bản của sản phẩm phần mềm? 1.2 Vai trò và mục đích của mô hình hoá trong quá trình phát triển phần mềm? 1.3 Tại sao lại cần phải có một qui trình phát triển phần mềm thống nhất? 1.4 Phân tích các đặc trưng cơ bản của cách tiếp cận hướng chức năng và hướng đối tượng trong quá trình phát triển phần mềm. 1.5 Nêu những mô hình cơ bản được ứng dụng để phát triển hệ thống hiện nay? 1.6 Chọn từ danh sách dưới đây những thuật ngữ thích hợp để điền vào các chỗ [( )] trong đoạn văn mô tả về hệ thống phần mềm. - 16 -
Hệ thống phần mềm hay gọi tắt là hệ thống, là tổ hợp các [(1)], [(2)] có quan hệ qua lại với nhau, [(3)] thông qua việc nhận các dữ liệu đầu vào (Input) và sản sinh ra những kết quả đầu ra (Output) thường là ở các dạng thông tin khác nhau nhờ một [(4)], biến đổi [(5)]. Chọn câu trả lời: a. cùng hoạt động hướng tới mục tiêu chung b. quá trình xử lý c. phần mềm d. có tổ chức e. phần cứng 1.7 Hãy chọn những thuật ngữ thích hợp nhất để điền vào các chỗ [( )] trong đoạn văn dưới đây mô tả về quá trình phân tích hướng chức năng. Để hiểu được những hệ thống lớn, phức tạp, chúng ta thường phải sử dụng nguyên lý [(1)], nghĩa là [(2)] chính thành các chức năng đơn giản hơn theo cách tiếp cận [(3)]. Qui trình này được lặp lại cho đến khi thu được những đơn thể chức năng tương đối đơn giản, dễ hiểu và thực hiện cài đặt chúng mà không làm tăng thêm độ phức tạp để liên kết chúng trong [(4)]. Chọn câu trả lời: a. từ trên xuống b. phân tách nhỏ các chức năng c. hệ thống d. chia để trị (devide and conquer) 1.8 Hãy chọn dãy các bước thực hiện trong danh sách dưới đây cho phù hợp với qui trình phát triển phần mềm theo mô hình "thác nước". (1) Xác định các yêu cầu (2) Thiết kế hệ thống (3) Cài đặt và kiểm tra hệ thống (4) Vận hành và bảo trì hệ thống (5) Phân tích hệ thống Chọn câu trả lời: a. (2) (1) (3) (5) (4) b. (1) (2) (3) (4) (5) c. (1) (5) (2) (3) (4) d. (1) (3) (2) (5) (4) - 17 -
CHƯƠNG II UML VÀ QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM Nội dung của chương II:  Giới thiệu tóm lược về ngôn ngữ mô hình hoá thống nhất UML  Các khái niệm cơ bản của phương pháp hướng đối tượng,  Mối quan hệ giữa các lớp đối tượng,  Quá trình phát triển phần mềm. Để xây dựng được một sản phẩm phần mềm tốt, đương nhiên là cần một phương pháp phù hợp. Phương pháp phát triển phù hợp là sự kết hợp của ba yếu tố: (i) Một tập hợp các khái niệm và mô hình, bao gồm các khái niệm cơ bản sử dụng trong phương pháp cùng với cách biểu diễn chúng (thường là dưới dạng đồ thị, biểu đồ). (ii) Một quá trình triển khai, bao gồm các bước thực hiện lần lượt, các hoạt động cần thiết. (iii) Một công cụ mạnh trợ giúp cho việc triển khai hệ thống chặt chẽ và nhanh chóng. UML là ngôn ngữ chuẩn giúp chúng ta thể hiện được các yếu tố nêu trên của phương pháp phân tích, thiết kế hướng đối tượng. 2.1 Tổng quát về UML UML là ngôn ngữ mô hình hoá, trước hết nó mô tả ký pháp thống nhất, ngữ nghĩa các định nghĩa trực quan tất cả các thành phần của mô hình ([1], [2]). UML được sử dụng để hiển thị, đặc tả, tổ chức, xây dựng và làm tài liệu các vật phẩm của quá trình phát triển phần mềm hướng đối tượng, đặc biệt là phân tích, thiết kế dưới dạng các báo cáo, biểu đồ, bản mẫu hay các trang web, v.v. UML là ngôn ngữ mô hình hoá độc lập với các công nghệ phát triển phần mềm. 2.1.1 Mục đích của UML Mục đích chính của UML: 1. Mô hình được các hệ thống (không chỉ hệ thống phần mềm) và sử dụng được tất cả các khái niệm hướng đối tượng một cách thống nhất. 2. Cho phép đặc tả, hỗ trợ để đặc tả tường minh (trực quan) mối quan hệ giữa các khái niệm cơ bản trong hệ thống, đồng thời mô tả được mọi trạng thái hoạt động của hệ thống đối tượng. Nghĩa là cho phép mô tả được cả mô hình tĩnh lẫn mô hình động một cách đầy đủ và trực quan. - 18 -
3. Tận dụng được những khả năng sử dụng lại và kế thừa ở phạm vi diện rộng để xây dựng được những hệ thống phức tạp và nhạy cảm như: các hệ thống động, hệ thống thời gian thực, hệ thống nhúng thời gian thực, v.v. 4. Tạo ra những ngôn ngữ mô hình hoá sử dụng được cho cả người lẫn máy tính. Tóm lại, UML là ngôn ngữ mô hình hoá, ngôn ngữ đặc tả và ngôn ngữ xây dựng mô hình trong quá trình phát triển phần mềm, đặc biệt là trong phân tích và thiết kế hệ thống hướng đối tượng. UML là ngôn ngữ hình thức, thống nhất và chuẩn hoá mô hình hệ thống một cách trực quan. Nghĩa là các thành phần trong mô hình được thể hiện bởi các ký hiệu đồ hoạ, biểu đồ và thể hiện đầy đủ mối quan hệ giữa các chúng một cách thống nhất và có logic chặt chẽ. Tuy nhiên cũng cần lưu ý: . UML không phải là ngôn ngữ lập trình, nghĩa là ta không thể dùng UML để viết chương trình. Nó cũng không phải là một công cụ CASE. Một số công cụ CASE như Rational Rose [8] sử dụng mô hình UML để phát sinh mã nguồn tự động sang những ngôn ngữ lập trình được lựa chọn như C++, Java, Visual C++, v.v. . UML cũng không phải là một phương pháp hay một quá trình phát triển phần mềm. Các ký hiệu UML được sử dụng trong các dự án phát triển phần mềm nhằm áp dụng những cách tiếp cận khác nhau cho quá trình phát triển phần mềm nhằm tách chu kỳ phát triển hệ thống thành những hoạt động, các tác vụ, các giai đoạn và các bước khác nhau. 2.1.2 Qui trình phát triển phần mềm thống nhất UML được phát triển để đặc tả quá trình phát triển phần mềm, nhằm mô hình hoá hệ thống. Qui trình phát triển phần mềm này gọi là qui trình phát triển phần mềm hợp nhất (USPD) hay qui trình hợp nhất Rational (RUP [8]), gọi tắt là qui trình hợp nhất (UP). UP bao gồm con người, dự án, sản phẩm, qui trình và công cụ. Con người là những người tham gia dự án để tạo ra sản phẩm phần mềm theo một qui trình với sự hỗ trợ của công cụ được cung cấp. UP là qui trình phát triển phần mềm được hướng dẫn bởi các ca sử dụng. Nghĩa là các yêu cầu của NSD được mô tả trong các ca sử dụng, là chuỗi các hành động được thực hiện bởi hệ thống nhằm cung cấp các dịch vụ, các thông tin cho khách hàng. Các ca sử dụng bao gồm chuỗi các công việc được xem là nền tảng để tạo ra mô hình thiết kế và cài đặt hệ thống. UP cũng là qui trình tập trung vào kiến trúc, được lặp và phát triển tăng trưởng liên tục. Kiến trúc của hệ thống phải được thiết kế nhằm đáp ứng các yêu cầu của các ca sử dụng chính, trong giới hạn của chuẩn phần cứng mà hệ thống sẽ chạy và của cấu trúc của cả hệ thống lẫn các hệ thống con. Tính lặp của quá trình phát triển phần mềm được thể hiện ở chỗ là một dự án được chia thành các dự án nhỏ và được thực hiện lặp lại trong từng bước thực hiện. Mỗi dự án nhỏ đều thực hiện phân tích, thiết kế, cài đặt - 19 -
và kiểm thử, v.v. Mỗi phần việc đó được phát triển tăng trường và cả dự án cũng được thực hiện theo sự tăng trưởng này. UP không chỉ tạo ra một hệ thống phần mềm hoàn chỉnh mà còn tạo ra một số sản phẩm trung gian như các mô hình. Các mô hình chính trong UP là mô hình nghiệp vụ (ca sử dụng), mô hình khái niệm, mô hình thiết kế, mô hình triển khai và mô hình trắc nghiệm. Các mô hình này có sự phụ thuộc theo vết phát triển, nghĩa là có thể lần theo từng mô hình để đến được mô hình trước. 2.1.3 Giới thiệu tổng quát về UML UML được xây dựng dựa chính vào: . Cách tiếp cận của Booch (Booch Approach), . Kỹ thuật mô hình đối tượng (OMT – Object Modeling Technique) của Rumbaugh, . Công nghệ phần mềm hướng đối tượng (OOSE – Object-Oriented Software Engineering) của Jacobson, . Đồng thời thống nhất được nhiều ký pháp, khái niệm của các phương pháp khác. Quá trình hình thành UML bắt đầu từ ngôn ngữ Ada (Booch) trước năm 1990 (hình 2-1). Ada / Booch 1990 Booch 91 OOSE OMT Jacobson Rumbaugh Booch 93 OOSE 94 OMT 94 1995 UML 0.9 Booch /Rumbaugh UML 0.9 Amigos 1997 UML 1.0 UML 1.1 11/ 1997 được chấp nhận Hình 2-1 Sự phát triển của UML Để hiểu và sử dụng tốt UML trong phân tích, thiết kế hệ thống, đòi hỏi phải nắm bắt được ba vấn đề chính: 1. Các phần tử cơ bản của UML, - 20 -
2. Những qui định liên kết giữa các phần tử, các qui tắc cú pháp, 3. Những cơ chế chung áp dụng cho ngôn ngữ mô hình hoá hệ thống. 2.1.4 Các phần tử của UML UML Các sự vật Các mối quan Các biểu Các quan sát hệ đồ Cấu trúc Hành vi Gộp nhóm Chú dẫn Phụ thuộc Ca sử dụng Ca sử dụng Kết hợp Lớp Logic Kết nhập Đối tượng Thành phần Tổng quát hoá Trình tự Sự tương tranh Ca sử dụng Sự tương tác Gói (kế thừa) Cộng tác Triển khai L ớp Máy trạng Mô hình Trạng thái Giao diện thái Hệ thống con Hoạt động Thành phần Khung công việc Thành phần Cộng tác Triển khai Nút Hình 2-2 Các thành phần cơ sở của UML Các quan sát Các quan sát (góc nhìn) theo các phương diện khác nhau của hệ thống cần phân tích, thiết kế. Dựa vào các quan sát để thiết lập kiến trúc cho hệ thống cần phát triển. Có năm loại quan sát: quan sát theo ca sử dụng, quan sát logic, quan sát thành phần, quan sát tương tranh và quan sát triển khai. Mỗi quan sát tập trung khảo sát và mô tả một khía cạnh của hệ thống (hình 2-3) và thường được thể hiện trong một số biểu đồ nhất định. Quan sát Quan sát thành phần logic Quan sát ca sử dụng Quan sát Quan sát triển khai tương tranh Hình 2-3 Các quan sát của hệ thống - 21 -
. Quan sát các ca sử dụng (hay trường hợp sử dụng): mô tả các chức năng, nhiệm vụ của hệ thống. Quan sát này thể hiện mọi yêu cầu của hệ thống, do vậy nó phải được xác định ngay từ đầu và nó được sử dụng để điều khiển, thúc đẩy và thẩm định hay kiểm tra các công việc của tất cả các giai đoạn của cả quá trình phát triển phần mềm. Nó cũng là cơ sở để trao đổi giữa các thành viên của dự án phần mềm và với khách hàng. Quan sát ca sử dụng được thể hiện trong các biểu đồ ca sử và có thể ở một vài biểu đồ trình tự, cộng tác, v.v. . Quan sát logic biểu diễn tổ chức logic của các lớp và các quan hệ của chúng với nhau. Nó mô tả cấu trúc tĩnh của các lớp, đối tượng và sự liên hệ của chúng thể hiện mối liên kết động thông qua sự trao đổi các thông điệp. Quan sát được thể hiện trong các biểu đồ lớp, biểu đồ đối tượng, biểu đồ tương tác, biểu đồ biến đổi trạng thái. Quan sát logic tập trung vào cấu trúc của hệ thống. Trong quan sát này ta nhận ra các bộ phận cơ bản cấu thành hệ thống thể hiện mọi quá trình trao đổi, xử lý thông tin cơ bản trong hệ thống. . Quan sát thành phần (quan sát cài đặt) xác định các mô đun vật lý hay tệp mã chương trình và sự liên hệ giữa chúng để tổ chức thành hệ thống phần mềm. Trong quan sát này ta cần bổ sung: chiến lược cấp phát tài nguyên cho từng thành phần, và thông tin quản lý như báo cáo tiến độ thực hiện công việc, v.v. Quan sát thành phần được thể hiện trong các biểu đồ thành phần và các gói. . Quan sát tương tranh (quan sát tiến trình) biểu diễn sự phân chia các luồng thực hiện công việc, các lớp đối tượng cho các tiến trình và sự đồng bộ giữa các luồng trong hệ thống. Quan sát này tập trung vào các nhiệm vụ tương tranh, tương tác với nhau trong hệ thống đa nhiệm. . Quan sát triển khai mô tả sự phân bổ tài nguyên và nhiệm vụ trong hệ thống. Nó liên quan đến các tầng kiến trúc của phần mềm, thường là kiến trúc ba tầng, tầng giao diện (tầng trình diễn), tầng logic tác nghiệp và tầng lưu trữ CSDL được tổ chức trên một hay nhiều máy tính. Quan sát triển khai bao gồm các luồng công việc, bộ xử lý và các thiết bị. Biểu đồ triển khai mô tả các tiến trình và chỉ ra những tiến trình nào trên máy nào. Các biểu đồ Biểu đồ là đồ thị biểu diễn đồ họa về tập các phần tử trong mô hình. Biểu đồ chứa đựng các nội dung của các quan sát dưới các góc độ khác nhau và một thành phần của hệ thống có thể xuất hiện trong một hay nhiều biểu đồ. UML cung cấp những biểu đồ trực quan để biểu diễn các khía cạnh khác nhau của hệ thống, bao gồm: . Biểu đồ ca sử dụng mô tả sự tương tác giữa các tác nhân ngoài và hệ thống thông qua các ca sử dụng. Các ca sử dụng là những nhiệm vụ chính, các dịch vụ, những trường hợp sử dụng cụ thể mà hệ thống cung cấp cho người sử dụng và ngược lại. . Biểu đồ lớp mô tả cấu trúc tĩnh, mô tả mô hình khái niệm bao gồm các lớp đối tượng và các mối quan hệ của chúng trong hệ thống hướng đối tượng. - 22 -
. Biểu đồ trình tự thể hiện sự tương tác của các đối tượng với nhau, chủ yếu là trình tự gửi và nhận thông điệp để thực thi các yêu cầu, các công việc theo thời gian. . Biểu đồ cộng tác tương tự như biểu đồ trình tự nhưng nhấn mạnh vào sự tương tác của các đối tượng trên cơ sở cộng tác với nhau bằng cách trao đổi các thông điệp để thực hiện các yêu cầu theo ngữ cảnh công việc. . Biểu đồ trạng thái thể hiện chu kỳ hoạt động của các đối tượng, của các hệ thống con và của cả hệ thống. Nó là một loại ôtômát hữu hạn trạng thái, mô tả các trạng thái, các hành động mà đối tượng có thể có và các sự kiện gắn với các trạng thái theo thời gian. . Biểu đồ hành động chỉ ra dòng hoạt động của hệ thống, bao gồm các trạng thái hoạt động, trong đó từ một trạng thái hoạt động sẽ chuyển sang trạng thái khác sau khi một hoạt động tương ứng được thực hiện. Nó chỉ ra trình tự các bước, tiến trình thực hiện cũng như các điểm quyết định và sự rẽ nhánh theo luồng sự kiện. . Biểu đồ thành phần chỉ ra cấu trúc vật lý của các thành phần trong hệ thống, bao gồm: các thành phần mã nguồn, mã nhị phân, thư viện và các thành phần thực thi. . Biểu đồ triển khai chỉ ra cách bố trí vật lý các thành phần theo kiến trúc được thiết kế của hệ thống. Các khái niệm cơ bản của biểu đồ và cách xây dựng các biểu đồ trên để phân tích, thiết kế hệ thống sẽ được giới thệu chi tiết ở các chương sau. 2.2 Các khái niệm cơ bản của phương pháp hướng đối tượng trong UML Để phát triển được hệ thống theo mô hình, phương pháp đã lựa chọn thì vấn đề quan trọng nhất là phải hiểu rõ những khái niệm cơ bản của phương pháp đó. Ở đây chúng ta cần thực hiện phân tích, thiết kế hệ thống theo cách tiếp cận hướng đối tượng, do vậy trước hết phải nắm bắt được những khái niệm cơ sở như: đối tượng, lớp, và các mối quan hệ giữa các lớp đối tượng. Những khái niệm này cũng là các phần tử cơ bản của ngôn ngữ mô hình hóa thống nhất UML. Mô hình hướng đối tượng được sử dụng để phát triển phần mềm dựa trên mô hình dữ liệu trừu tượng và khái niệm lớp để chỉ ra những đặc tính chung các cấu trúc dữ liệu được sử dụng để mô hình hoá hệ thống. Hệ thống các khái niệm cơ bản của phương pháp hướng đối tượng được mô tả như trong hình 2-4. 2.2.1 Các đối tượng Đối tượng là khái niệm cơ sở quan trọng nhất của cách tiếp cận hướng đối tượng. Đối tượng là một khái niệm, một sự trừu tượng hoá hay một sự vật có nghĩa trong bài toán đang khảo sát. Đó chính là các mục mà ta đang nghiên cứu, đang thảo luận về chúng. Đối tượng là thực thể của hệ thống, của CSDL và được xác định thông qua định danh của chúng. Thông thường các đối tượng được mô tả bởi các danh từ riêng - 23 -
(tên gọi) hoặc được tham chiếu tới trong các mô tả của bài toán hay trong các thảo luận với người sử dụng. Có những đối tượng là những thực thể có trong thế giới thực như người, sự vật cụ thể, hoặc là những khái niệm như một công thức, hay khái niệm trừu tượng, v.v. Có một số đối tượng được bổ sung vào hệ thống với lý do phục vụ cho việc cài đặt và có thể không có trong thực tế. Đối tượng là những thực thể được xác định trong thời gian hệ thống hoạt động. Trong giai đoạn phân tích, ta phải đảm bảo rằng các đối tượng đều được xác định bằng các định danh. Đến khâu thiết kế, ta phải lựa chọn cách thể hiện những định danh đó theo cách ghi địa chỉ bộ nhớ, gán các số hiệu, hay dùng tổ hợp một số gái trị của một số thuộc tính để biểu diễn. Theo quan điểm của người lập trình, đối tượng được xem như là một vùng nhớ được phân chia trong máy tính để lưu trữ dữ liệu (thuộc tính) và tập các hàm thao tác trên dữ liệu được gắn với nó. Bởi vì các vùng nhớ được phân hoạch là độc lập với nhau nên các đối tượng có thể tham gia vào nhiều chương trình khác nhau mà không ảnh hưởng lẫn nhau. Kế thừa Lớp Hàm Bao gói Quan hệ Cá thể Đối tượng Thông điệp Đa xạ Hình 2-4 Những khái niệm cơ bản của phương pháp hướng đối tượng 2.2.2 Lớp đối tượng Đối tượng là thể hiện, là một đại biểu của một lớp. Lớp là một mô tả về một nhóm các đối tượng có những tính chất (thuộc tính) giống nhau, có chung các hành vi ứng xử (thao tác gần như nhau), có cùng mối liên quan với các đối tượng của các lớp khác và có chung ngữ nghĩa trong hệ thống. Lớp chính là cơ chế được sử dụng để phân loại các đối tượng của một hệ thống. Lớp thường xuất hiện dưới dạng những danh từ chung trong các tài liệu mô tả bài toán hay trong các thảo luận với người sử dụng. Cũng như các đối tượng, lớp có thể là những nhóm thực thể có trong thế giới thực, cũng có những lớp là khái niệm trừu tượng và có những lớp được đưa vào trong thiết kế để phục vụ cho cài đặt hệ thống, v.v. Lớp và mối quan hệ của chúng có thể mô tả trong các biểu đồ lớp biểu đồ đối tượng và một số biểu đồ khác của UML. Trong biểu đồ lớp, lớp được mô tả bằng một hình hộp - 24 -
chữ nhật, trong đó có tên của lớp, có thể có các thuộc tính và các hàm (phương thức) như hình 2-5. a/ Tên của lớp b/ Tên và thuộc tính c/ Tên, thuộc tính và phương thức Hình 2-5 Các ký hiệu mô tả lớp trong UML Chúng ta nên đặt tên theo một qui tắc thống nhất như sau: + Tên của lớp thì chữ cái đầu của tất cả các từ đều viết hoa, ví dụ: SinhVien, HocSinh, KhachHang, v.v. + Tên của đối tượng, tên của thuộc tính thì viết hoa chữ cái đầu của các từ trừ từ đầu tiên, ví dụ: hoTen, danhSachSV, v.v. + Tên của hàm (phương thức) viết giống như tên của đối tượng nhưng có thêm cặp ngoặc đơn ‘(‘ và ‘)’, ví dụ: hienThi(), nhapDiem(), v.v. Trong biểu đồ ở giai đoạn phân tích, một lớp có thể chỉ cần có tên lớp, tên và thuộc tính, hoặc có cả tên gọi, thuộc tính và các phương thức như hình 2-5. 2.2.3 Các giá trị và các thuộc tính của đối tượng Giá trị (value) là một phần của dữ liệu. Các giá trị thường là các số hoặc là các ký tự. Thuộc tính của đối tượng là thuộc tính của lớp được mô tả bởi giá trị của mỗi đối tượng trong lớp đó. Ví dụ sv1: SinhVien hoTen = Van Ba tuoi = 20 Hình 2-6 Ký hiệu đối tượng trong UML “Van Ba” và 20 là hai giá trị tương ứng với hai thuộc tính hoTen, tuoi của đối tượng sv1 trong lớp SinhVien. Không nên nhầm lẫn giá trị với đối tượng. Các đối tượng có định danh chứ không phải là các giá trị. Có thể có ba sinh viên cùng tên “Van Ba”, nhưng trong hệ thống các sinh viên này phải được quản lý theo định danh để xác định duy nhất từng đối tượng. Giá trị có thể là các giá trị của các kiểu dữ liệu nguyên thuỷ như các kiểu số hoặc các kiểu xâu ký tự, hoặc là tập hợp của các giá trị nguyên thuỷ. Các dữ liệu thành phần của một lớp có thể được bao gói thông qua các thuộc tính quản lý sự truy nhập để phục vụ việc che giấu thông tin của phương pháp hướng đối tượng. Trong UML ta có thể sử dụng các ký hiệu để đặc tả các thuộc tính đó. - 25 -
Ký hiệu ‘+’ đứng trước tên thuộc tính, hàm xác định tính công khai (public), mọi đối tượng trong hệ thống đều nhìn thấy được. Nghĩa là mọi đối tượng đều có thể truy nhập được vào dữ liệu công khai. Trong Rose [8] ký hiệu là ổ khoá không bị khoá. ‘#’ đứng trước tên thuộc tính, hàm xác định tính được bảo vệ (protected), chỉ những đối tượng có quan hệ kế thừa với nhau nhìn thấy được. Trong Rose ký hiệu là ổ khoá bị khoá, nhưng có chìa để bên cạnh. ‘-‘ đứng trước tên thuộc tính, hàm xác định tính sở hữu riêng (private), chỉ các đối tượng trong cùng lớp mới nhìn thấy được. Trong Rose ký hiệu là ổ khoá bị khoá và không có chìa để bên cạnh. Trong trường hợp không sử dụng một trong ba ký hiệu trên thì đó là trường hợp mặc định. Thuộc tính quản lý truy cập mặc định của những hệ thống khác nhau có thể khác nhau, ví dụ trong C++, các thuộc tính mặc định trong lớp được qui định là private, còn trong Java lại qui định khác, đó là những thuộc tính rộng hơn private. Những thuộc tính trên thiết lập quyền truy cập cho mọi đối tượng trong các lớp, các gói, các hệ thống con của hệ thống phần mềm [2]. 2.2.4 Các thao tác và phương thức Thao tác là một hàm hay thủ tục có thể áp dụng (gọi hàm) cho hoặc bởi các đối tượng trong một lớp. Khi nói tới một thao tác là ngầm định nói tới một đối tượng đích để thực hiện thao tác đó. Ví dụ, thao tác (hàm) hienThi() của lớp MonHoc khi gọi để hiển thị các về sinh viên học một môn học cụ thể như “Lập trình hướng đối tượng” chẳng hạn. Một phương thức là một cách thức cài đặt của một thao tác trong một lớp [5]. Một số thao tác có thể là đa xạ, được nạp chồng, nghĩa là nó có thể áp dụng cho nhiều lớp khác nhau với những nội dung thực hiện có thể khác nhau, nhưng cùng tên gọi. Ví dụ lớp ThietBi có hàm tinhGia(). Hàm này có thể nạp chồng, bởi vì có nhiều phương thức (công thức) tính giá bán khác nhau tuỳ thuộc vào từng loại thiết bị. Tất cả các phương thức này đều thực hiện một nhiệm vụ tinhGia(), nhưng được cài đặt với nội dung (các đoạn chương trình) khác nhau. Hệ thống hướng đối tượng tự động chọn phương thức tương ứng với ngữ cảnh của đối tượng đích để thực hiện. Tương tự như các dữ liệu thành phần, các phương thức cũng được quản lý truy cập và được ký hiệu như trên. Lưu ý: Một số tác giả ([2], [4], [6], [9]) không phân biệt thao tác, hàm với phương thức mà có thể đồng nhất chúng với nhau trong quá trình phân tích, thiết kế và lập trình. Trong các phần sau chúng ta gọi chung là hàm hoặc hàm thành phần. 2.3 Các mối quan hệ giữa các lớp Hệ thống hướng đối tượng là tập các đối tượng tương tác với nhau để thực hiện công việc theo yêu cầu. Quan hệ là kết nối ngữ nghĩa giữa các lớp đối tượng, trong đó thể hiện mối liên quan về các thuộc tính, các thao tác của chúng với nhau trong hệ - 26 -
thống. Các quan hệ này được thể hiện chính trong biểu đồ lớp. Giữa các lớp có bốn quan hệ cơ bản: . Quan hệ kết hợp, . Quan hệ kết tập, . Quan hệ tổng quát hóa, kế thừa, . Quan hệ phụ thuộc. 2.3.1 Sự liên kết và kết hợp giữa các đối tượng Một liên kết là một sự kết nối vật lý hoặc logic giữa các đối tượng với nhau. Phần lớn các liên kết là sự kết nối giữa hai đối tượng với nhau. Tuy nhiên cũng có những liên kết giữa ba hoặc nhiều hơn ba đối tượng. Nhưng các ngôn ngữ lập trình hiện nay hầu như chỉ cài đặt những liên kết (phép toán) nhiều nhất là ba ngôi. Một sự kết hợp là một mô tả về một nhóm các liên kết có chung cấu trúc và ngữ nghĩa như nhau. Vậy, liên kết là một thể hiện của lớp. Liên kết và kết hợp thường xuất hiện ở dạng các động từ trong các tài liệu mô tả bài toán ứng dụng. Hình 2-7 mô tả các ký hiệu cho quan hệ liên kết và kết hợp. NoiBai: SanBay GiaLam: SanBay maSo = HN1 maSo = HN2 tenGoi = Sân bay quốc tế tenGoi = Sân bay nội địa phục vụ HaNoi: TinhThanh phục vụ tenGoi = Thu đô Hà Nội soDan = 5000000 Hình 2-7 (a) Liên kết giữa các đối tượng Hai đối tượng thuộc lớp SanBay: Nội Bài và Gia Lâm cùng liên kết với đối tượng Hà Nội của lớp TinhThanh theo quan hệ phục vụ. Quan hệ liên kết giữa hai đối tượng được biểu diễn bằng đoạn thẳng nối chúng với nhau và có tên gọi (nhãn của quan hệ). Nhãn của các quan hệ thường là các động từ. Khi muốn biểu diễn cho quan hệ một chiều thì sử dụng mũi tên để chỉ rõ hướng của quan hệ. SanBay phục vụ TinhThanh maSo tenGoi tenGoi danSo Hình 2-7 (b) Quan hệ kết hợp giữa các lớp Khi mô hình không có sự nhập nhằng thì tên của kết hợp là tuỳ chọn. Sự nhập nhằng sẽ xuất hiện khi giữa hai lớp có nhiều quan hệ kết hợp, ví dụ: giữa lớp NhanVien và lớp CongTy có hai quan hệ làm việc ở và có cổ phần trong. Khi có - 27 -
nhiều quan hệ như thế thì nên gán tên vào mỗi đường nối hoặc tên của vai trò ở mỗi đầu của quan hệ để tránh sự nhập nhằng. Làm việc ở NhanVien CongTy hoTen Có cổ phần trong tenGoi nhiemVu taiKhoan Hình 2-7 (c) Quan hệ kết hợp giữa các lớp Lưu ý: không nên nhầm lẫn liên kết với giá trị. Giá trị là dữ liệu nguyên thuỷ như là dữ liệu số hoặc xâu ký tự. Liên kết là mối liên quan giữa hai đối tượng. Trong giai đoạn phân tích ta phải mô hình (xác định) tất cả các tham chiếu tới các đối tượng thông qua các liên kết và nhận dạng được các nhóm liên kết tương tự thông qua các quan hệ kết hợp. Đến giai đoạn thiết kế ta có thể chọn cấu trúc con trỏ, khóa ngoại, hoặc một số cách khác để cài đặt những quan hệ đó. Ví dụ: mô hình phân tích ở hình 2-7 (b) được phát triển sang giai đoạn thiết kế như sau: SanBay TinhThanh maSo tenGoi tenGoi danSo cacSanBay Hình 2-8 Mô hình thiết kế các lớp Trong đó, lớp TinhThanh có thêm thuộc tính cacSanBay có thể là danh sách hoặc là cấu trúc mảng, hay con trỏ, v.v. Ta cũng có thể thiết kế theo cách khác, thay vì bổ sung thuộc tính cacSanBay vào lớp TinhThanh thì bổ sung oTinhThanh vào lớp SanBay. 2.3.2 Bội số Quan hệ kết hợp thường là quan hệ hai chiều: một đối tượng kết hợp với một số đối tượng của lớp khác và ngược lại. Để xác định số các đối tượng có thể tham gia vào mỗi đầu của mối quan hệ ta có thể sử dụng khái niệm bội số. Bội số xác định số lượng các thể hiện (đối tượng) của một lớp trong quan hệ kết hợp với các đối tượng của lớp khác. Cũng cần phân biệt bội số (hay bản số) với lực lượng. Bội số là ràng buộc về kích cỡ của một tuyển tập, còn lực lượng là đếm số phần tử của tuyển tập đó. Do đó, bội số là sự ràng buộc về lực lượng của các phần tử trong một lớp tham gia vào quan hệ xác định trước. Trong UML các bội số được biểu diễn như sau: 1 LopA Chính xác 1 (nếu không nhập nhằng có thể không gì cả, được xem mặc định là 1) * LopA - 28 -
Nhiều (0 *) n k LopA Số lượng được xác định giữa số n và k ( 0). n * LopA Số lượng được xác định bởi số n cho đến nhiều (n 0). Để phân biệt chiều của quan hệ kết hợp ta có thể sử dụng mũi tên chỉ chiều kết hợp. Ví dụ: có 1 * 0 * Nguoi Oto sở hữu của Hình 2-9 Quan hệ kết hợp hai chiều giữa hai lớp Hình 2-9 mô tả như sau: mỗi người trong lớp Nguoi có thể không có hoặc có nhiều ô tô (thuộc lớp Oto) và ngược lại một ô tô phải là sở hữu của ít nhất một người nào đó thuộc lớp Nguoi. 2.3.3 Các vai trò trong quan hệ Vai trò là tên gọi một nhiệm vụ thường là một danh từ được gán cho một đầu của quan hệ kết hợp. Hình 2-10 mô tả hai lớp SanBay và lớp CacChuyenBay có quan hệ kết hợp với nhau. Một sân bay có thể là điểm đến của chuyến bay này và lại có thể là điểm xuất phát của chuyến bay khác. Ngược lại một chuyến bay bao giờ cũng phải bay từ một sân bay này tới một sân bay khác. Nơi xuất phát * SanBay CacChuyenBay maSo Nơi đến * soHieuChuyen Bay tenGoi lichBay Hình 2-10 Vai trò trong các quan hệ kết hợp Khi mô hình không có sự nhập nhằng thì tên của vai trò là tuỳ chọn. Sự nhập nhằng sẽ xuất hiện khi giữa hai lớp có nhiều quan hệ như hình 2-10, hoặc khi một lớp lại có quan hệ với chính nó (quan hệ đệ qui). Ví dụ: một người có thể là con của hai người (cha-mẹ) và hai cha -mẹ lại có thể có nhiều con. Quan hệ này có thể mô tả như trong hình 2-11. Cha-mẹ Nguoi 2 + tenGoi - tuoi con - 29 -
* Hình 2-11 Vai trò trong các quan hệ kết hợp 2.3.4 Quan hệ kết tập (quan hệ gộp) Kết tập (gộp) là một loại của quan hệ kết hợp, tập trung thể hiện quan hệ giữa tổng thể và bộ phận (Whole / part). Kết tập thường biểu diễn cho quan hệ “có” (has-a), “là bộ phận của” (is-a-part-of), hoặc “bao gồm” (contains), v.v. thể hiện mối quan hệ một lớp tổng thể có, gồm, chứa hay liên kết với một hoặc nhiều lớp thành phần. Người ta chia quan hệ kết tập thành ba loại: . Kết tập thông thường . Kết tập chia sẻ và . Kết tập hợp thành hay quan hệ hợp thành. Kết tập thông thường Quan hệ kết tập thông thường, gọi tắt là kết tập thể hiện mối liên kết giữa hai lớp, trong đó đối tượng của lớp này bao gồm một số đối tượng của lớp kia, song không tồn tại trong nội tại của lớp đó. Lớp phía bộ phận cũng chỉ là một bộ phận logic của phía tổng thể và chúng không được chia sẻ với các lớp khác. Ví dụ: một hạm đội của lớp HamDoi gồm một số (3 10) tàu chiến của lớp TauChien, nhưng tàu chiến không chứa trong lớp HamDoi. Vậy, lớp HamDoi có quan hệ kết tập với TauChien. UML sử dụng ký hiệu: để biểu diễn quan hệ kết tập và luôn được gắn với phía tổng thể. Hình 2-12 thể hiện quan hệ giữa lớp HamDoi và lớp TauChien. 3 10 HamDoi TauChien Hình 2-12 Quan hệ kết tập thông thường Trong quan hệ này, việc quản lý các đối tượng của các lớp liên quan là khác nhau. Ta có thể loại bỏ một số tàu chiến của một hạm đội sao cho số còn lại ít nhất là 3, tương tự có thể bổ sung vào một số tàu chiến sao cho không quá 10. Nhưng khi đã loại bỏ một hạm đội thì phải loại bỏ tất cả các tàu chiến của hạm đội đó vì mỗi tàu chiến chỉ thuộc một hạm đội. Nói một cách khác, một đối tượng của lớp phía bộ phận sẽ không thể tồn tại độc lập nếu nó không phải là một phần của phái tổng thể. Kết tập chia sẻ Quan hệ kết tập chia sẻ là loại kết tập, trong đó phía bộ phận có thể tham gia vào nhiều phía tổng thể. Ví dụ: một dự án của lớp DuAn có nhiều nhân viên của lớp NhanVien tham gia và một nhân viên có thể tham gia vào nhiều (hai) dự án. UML sử dụng ký hiệu: - 30 -
để biểu diễn quan hệ kết tập chia sẻ và luôn được gắn với phía tổng thể. Hình 2-13 thể hiện quan hệ giữa lớp DuAn và lớp NhanVien. 0 2 * DuAn NhanVien Hình 2-13 Quan hệ kết tập thông thường Mỗi dự án có thể có nhiều người tham gia và mỗi người lại có thể tham gia nhiều nhất là hai dự án. Trong quan hệ này, ta có thể loại bỏ, hay thành lập một dự án (phía tổng thể) nhưng không nhất thiết phải loại bỏ, hay phải tuyển thêm những người tham gia (phía bộ phận) vào dự án như kiểu kết tập ở trên. Tuy nhiên khi xử lý các mối quan hệ đó thì phải cập nhật lại các mối liên kết của các nhân viên tham gia vào các dự án tương ứng. Kết tập hợp thành Quan hệ chỉ ra một vật có chứa một số bộ phận và các bộ phận đó tồn tại vật lý bên trong vật tổng thể. Do vậy khi thực hiện huỷ bỏ, hay thiết lập mới bên tổng thể thì các bộ phận bên thành phần cũng sẽ bị huỷ bỏ hoặc phải được bổ sung. Ví dụ: lớp Window chứa các lớp Text, Menu và DialogBox. Trong UML có hai cách biểu diễn quan hệ hợp thành như sau: * Text Window * Text chứa * Window Menu * Menu * DialogBox * DialogBox Hình 2-14 Quan hệ kết tập hợp thành 2.3.5 Quan hệ tổng quát hoá Tổng quát hoá và chuyên biệt hoá là hai cách nhìn dưới / lên (buttom–up) và trên/xuống (top-down) về sự phân cấp các lớp, mô tả khả năng quản lý cấp độ phức tạp của hệ thống bằng cách trừu tượng hoá các lớp. Tổng quát hoá là đi từ các lớp dưới lên sau đó hình thành lớp tổng quát (lớp trên, lớp cha), tức là cây cấu trúc các lớp từ lá đến gốc. Chuyên biệt hoá là quá trình ngược lại của tổng quát hoá, nó cho phép tạo ra các lớp dưới (lớp con) khác nhau của lớp cha. Trong UML, tổng quát hoá chính là quan hệ kế thừa giữa hai lớp. Nó cho phép lớp con (lớp dưới, lớp kế thừa, hay lớp dẫn xuất) kế thừa trực tiếp các thuộc tính và các hàm thuộc loại công khai, hay được bảo vệ (protected) của lớp cha (lớp cơ sở, lớp trên). Trong quan hệ tổng quát hoá có hai loại lớp: lớp cụ thể và lớp trừu tượng. - 31 -
Lớp cụ thể (Concrete Class) là lớp có các đại diện, các thể hiện cụ thể. Ngược lại, lớp trừu tượng (Abstract Class) là lớp không có thể hiện (đối tượng) cụ thể trong hệ thống thực. Các lớp con cháu của lớp trừu tượng có thể là lớp trừu tượng, tuy nhiên trong cấu trúc phân cấp theo quan hệ tổng quát hoá thì mọi nhánh phải kết thúc (lớp lá) bằng các lớp cụ thể. Ta có thể định nghĩa các hàm trừu tượng cho các lớp trừu tượng, đó là những hàm chưa được cài đặt nội dung thực hiện trong lớp chúng được khai báo. Những hàm trừu tượng này sẽ được cài đặt trong các lớp con cháu sau đó ở những lớp cụ thể. Ví dụ: Lớp NhanVien có ký hiệu {abstract} sau hoặc dưới tên lớp là lớp trừu tượng, và do vậy nó không có đối tượng cụ thể. Hai lớp con: lớp NguoiBanHang và lớp CongNhan là hai lớp cụ thể. Hai lớp này có những thuộc tính, thao tác giống lớp NhanVien như có các thuộc tính: hoTen, diaChi và có các hàm tinhLuong(), hienThi(), ngoài ra mỗi lớp còn có thể bổ sung thêm một số thuộc tính, thao tác để đặc tả cho từng nhóm đối tượng cụ thể. Lớp NguoiBanHang được bổ sung thêm thuộc tính soluongBanDuoc còn lớp CongNhan được bổ sung thuộc tính soLuongSanPham sản xuất được. Cấu trúc phân cấp của lớp NhanVien được xác định như hình 2-15. {abstract} Hình 2-15 Lớp trừu tượng và cụ thể trong quan hệ tổng quát hoá Lưu ý: . Quan hệ tổng quát và kết hợp là hai quan hệ liên quan đến hai lớp, nhưng chúng có những điểm khác nhau. Quan hệ kết hợp mô tả mối liên kết giữa hai hoặc nhiều hơn đối tượng còn quan hệ khái quát mô tả các phương diện khác nhau của cùng một thể hiện. . Trong giai đoạn phân tích, các quan hệ kết hợp là quan trọng hơn quan hệ tổng quát hoá. Kết hợp bổ sung thêm các thông tin cho các lớp. Ngược lại, tổng quát hoá là loại bỏ những thông tin bị chia sẻ ở các lớp con cháu vì chúng được kế thừa từ lớp cha. . Trong giai đoạn thiết kế thì tổng quát hoá lại quan trọng hơn. Người phát triển hệ thống quan tâm để phát hiện ra những cấu trúc dữ liệu ở khâu phân tích và phát hiện ra các hành vi ở khâu thiết kế. Tổng quát hoá cung cấp cơ chế sử dụng lại để thể hiện chính xác các hành vi và mã hoá của các thư viện của các lớp. . Quan hệ kết tập và tổng quát cũng khác nhau. Cả hai đều làm xuất hiện cấu trúc cây thông qua bao đóng bắc cầu của quan hệ cơ sở, nhưng quan hệ tổng - 32 -
quát là mối quan hệ “hoặc” (OR) còn quan hệ kết tập là mối quan hệ “và” (AND). Hình 2-16 mô tả sự khác nhau của quan hệ tổng quát hoá và kết tập. TaiLieu Sach Sach TapChi ChuongMot ChuongHai KetLuan Hình 2-16 Quan hệ tổng quát hoá ngược lại với quan hệ kết tập 2.3.6 Kế thừa bội Kế thừa bội cho phép một lớp được kế thừa các thuộc tính, các thao tác và các quan hệ kết hợp từ nhiều lớp cơ sở. Trong quan hệ kế thừa bội có thể dẫn đến sự pha trộn thông tin từ nhiều nguồn dữ liệu khác nhau từ các lớp được kế thừa. Quan hệ kế thừa đơn, một lớp được kế thừa từ một lớp trên, thường tạo ra cấu trúc cây, còn kế thừa bội lại tổ chức các lớp thành đồ thị định hướng phi chu trình. Kế thừa bội là cơ chế mạnh trong mô hình hệ thống, nhưng đồng thời cũng sẽ tạo ra nhiều phức tạp về tính nhập nhằng, không nhất quán dữ liệu. Kế thừa bội từ những lớp phân biệt Một lớp có thể kế thừa từ nhiều lớp cơ sở khác nhau. Ví dụ lớp Nguoi là cơ sở để tạo ra hai lớp con: HDQuanTri (những người trong hội đồng quản trị) và KinhDoanh (những người kinh doanh). Từ các lớp trên lại xây dựng các lớp BanGiamDoc, CoDong (những người đóng cổ phần) kế thừa từ lớp HDQuanTri, lớp NhanVienCT (những người làm việc thường xuyên trong công ty) và NhanVienHD (những người làm việc theo hợp đồng) kế thừa từ lớp KinhDoanh. Trong Công ty lại có những người vừa là cổ đông, vừa là nhân viên. Những người đó chính là các đối tượng của lớp NhanVienCoDong kế thừa từ hai lớp con CoDong và NhanVienCongTy như hình 2-17(a). Nguoi HDQuanTri KinhDoanh BanGiamDoc CoDong NhanVienCT NhanVienHD NhanVienCoDong - 33 -
Hình 2-17(a) Kế thừa bội từ hai lớp khác nhau và có lớp cơ sở chung Kế thừa bội không có lớp cơ sở chung Kế thừa bội như trên là kế thừa có lớp cơ sở chung (lớp Nguoi). Chúng ta có thể tạo ra lớp kế thừa bội từ nhiều lớp mà chúng lại không có lớp cơ sở chung. Loại kế thừa này thường xuất hiện khi ta muốn pha trộn một số chức năng của các lớp thư viện khác nhau. Ví dụ: chúng ta hãy xét mô hình của chương trình đánh cờ. Trước khi đi một nước cờ, chương trình phải nghiên cứu vị trí của các quân cờ và các nước đi tiếp theo sao cho nước đi đó là có thể dẫn đến chiến thắng nhanh nhất. Trong hình 2-13 (b), mỗi đối tượng của lớp SearchTree (cây tìm kiếm) có thể là đối tượng của lớp MoveSubtree (cây con các nước đi) hoặc của lớp PossibleMove (lớp các nước có thể chọn). Bản thân lớp MoveSubtree lại có thể chứa các SearchTree nhỏ hơn. Mỗi nước đi của lớp Move lại có thể là nước đi có thể (PossibleMove) hoặc lớp các nước đi hiện thời (ActualMove). Lớp PossibleMove kế thừa hành vi chung của lớp Move và lớp SearchTree. SearchTree Move MoveSubtree PossibleMove ActualMove Hình 2-17(b) Kế thừa bội không có lớp có sở chung 2.3.7 Quan hệ phụ thuộc Sự phụ thuộc là một loại quan hệ liên kết giữa hai phần tử trong mô hình, trong đó thể hiện sự thay đổi trong một phần tử sẽ kéo theo sự thay đổi của phần tử kia. Quan hệ kết hợp thường là quan hệ hai chiều, nhưng quan hệ phụ thuộc lại thường là quan hệ một chiều, thể hiện một lớp phụ thuộc vào lớp khác. Lớp A phụ thuộc vào lớp B khi: . Lớp A sử dụng một đối tượng của lớp B như là tham số trong các thao tác, . Trong các thao tác của lớp A có truy nhập tới các đối tượng của lớp B, . Khi thực hiện một thao tác nào đó trong lớp A lại phải tham chiếu tới miền xác định của lớp B. . Lớp A sử dụng các giao diện của lớp B. Tương tự, hai gói (package) có thể phụ thuộc vào nhau khi có một lớp ở một gói phụ thuộc vào lớp của gói kia. Trong UML, quan hệ phụ thuộc được thể hiện bằng mũi tên đứt nét. Ví dụ, hình 2-18 mô tả quan hệ phụ thuộc giữa hai lớp và phụ thuộc của hai gói. LớpA LớpB GóiA GóiB - 34 -
Hình 2-18 Quan hệ phụ thuộc giữa các lớp và các gói 2.4 Các gói Để hiểu được những hệ thống lớn, phức tạp có nhiều lớp đối tượng, thì chúng ta phải có cách chia các lớp đó thành một số nhóm được gọi là gói. Gói là một nhóm các phần tử của mô hình gồm các lớp, các mối quan hệ và các gói nhỏ hơn. Cách tổ chức hệ thống thành các gói (hệ thống con) chính là cách phân hoạch mô hình thành các đơn vị nhỏ hơn để trị dễ hiểu và dễ quản lý hơn. Gói được mô tả trong UML gồm tên của gói, có thể có các lớp, gói nhỏ khác và được ký hiệu như hình 2-19. GoiA LopA LopB GoiA1 Hình 2-19 Gói các lớp trong UML Khi phân chia các lớp thành các gói, chúng ta có thể dựa vào: các lớp chính (thống trị), các mối quan hệ chính, các chức năng chính. Theo cách phân chia đó chúng ta có thể chia hệ thống thành các phân hệ phù hợp với cách phân chia trong hệ thống thực. Ví dụ, hệ thống quản lý thư viện có thể tổ chức thành bốn gói: gói giao diện, gói nghiệp vụ, gói CSDL và gói tiện ích như hình 2-20. Trong đó, . Gói giao diện (UI – User Interface): bao gồm các lớp giao diện với người dùng, cho các khả năng quan sát và truy nhập vào dữ liệu. Các đối tượng trong gói này có thể thực hiện các thao tác trên các đối tượng tác nghiệp để truy vấn hay nhập dữ liệu. . Gói nghiệp vụ (Business Package): chứa các lớp thực thể thuộc lĩnh vực bài toán ứng dụng. . Gói CSDL: chứa các lớp dịch vị cho các lớp ở gói tác nghiệp trong việc tổ chức, quản lý và lưu trữ dữ liệu. . Gói tiện ích: chứa các lớp dịch vụ cho các gói khác của hệ thống. Các gói của một hệ thống thường có mối quan hệ với nhau, như quan hệ phụ thuộc. Gói UI Gói tiện ích Gói nghiệp vụ Gói CSDL - 35 -
Hình 2-20 Tổ chức các gói của hệ thống thư viện 2.5 Các qui tắc ràng buộc và suy diễn Trong mô hình hoá hệ thống với UML, ta có thể sử dụng ngôn ngữ ràng buộc đối tượng OCL (Object Constraints Language) [4] để đặc tả chính xác các phần tử của hệ thống và các ràng buộc chặt chẽ giữa các mối quan hệ, giới hạn phạm vi của mô hình hệ thống cho phù hợp với điều kiện ràng buộc thực tế. Trong UML có hai qui tắc chính: 1. Qui tắc ràng buộc (Constraint Rule) được sử dụng để giới hạn phạm vi của mô hình, ví dụ các qui tắc hạn chế, qui định rõ phạm trù của các mối quan hệ như kết hợp, kế thừa hay khả năng nạp chồng trong các lớp. 2. Qui tắc suy dẫn (Derivation Rule) chỉ ra cách các sự vật có thể suy dần được, ví dụ tuổi của một người có thể suy ra được từ ngày / tháng / năm hiện thời trừ đi ngày / tháng / năm sinh. Lưu ý: Các qui tắc ràng buộc và suy dẫn thường được đặt trong cặp dấu ngoặc ‘{‘ và ‘}’ ở bên cạnh những phần tử của mô hình, thường là các thuộc tính, hay các mối quan hệ cần phải tuân theo. Ví dụ: 1/ Khi mô tả mối quan hệ giữa hai lớp DangPhai và ChinhTriGia, ta có thể sử dụng qui tắc ràng buộc để khống chế các đối tượng tham gia vào các quan hệ đó. Ví dụ, trong các đảng phái chính trị có qui định rằng lãnh tụ của một đảng phải là đảng viên của chính đảng đó. Khi đó quan hệ “Chủ tịch của” một đảng phải là tập con {Subset} của quan hệ “đảng viên của” đảng đó và được mô tả trong UML như hình 2- 21 (a). 1 * Đảng viên của 1 ChinhTriGia {Subset} ĐangPhai 1 Chủ tịch của 1 Hình 2-21 (a) Mối ràng buộc giữa hai quan hệ 2/ Các thuộc tính có thể bị khống chế, bị giới hạn trong phạm vi xác định, ví dụ: điều kiện {0 mau 255} chỉ ra rằng thuộc tính mau (màu) có giá trị trong phạm vi các số nguyên từ 0 đến 255. 3/ Một số thuộc tính có thể được suy dẫn từ những thuộc tính khác. Ví dụ khi thiết kế lớp SanPham có thuộc tính giaBan và giaSanXuat. Trong kinh doanh ta có thể xác định được ngay cách tính lợi nhuận loiNhuan = giaBan – giaSanXuat. Cách tính và những qui định trên có thể mô tả như hình 2-21 (b). - 36 -
SanPham giaBan giaSanXuat / loiNhuan {loiNhuan = giaBan - giaSanXuat} Hình 2-21 (b) Qui tắc suy dẫn trong OCL Trong hình trên, ký hiệu “/” được sử dụng để chỉ ra rằng thuộc tính loiNhuan là được suy dẫn ra theo qui tắc được gắn bên cạnh của lớp SanPham. Lưu ý:  Quan hệ tổng quát hoá chỉ áp dụng với các qui tắc hạn chế (bị ràng buộc) chứ không áp dụng được với qui tắc suy dẫn, nghĩa là có thể được nạp chồng, rời nhau, tổng quát hoá toàn bộ hay một phần.  Các qui tắc hạn chế có thể viết dưới dạng các biểu thức với toán tử ‘.’ (toán tử xác định thành phần) như trong các ngôn ngữ lập trình hướng đối tượng. Ví dụ: HopDongBaoHiem.soNguoiMuaBH > 0 Oto.NguoiLai.bangLaiXe = True 2.6 Quá trình phát triển phần mềm Phần mềm là một sản phẩm được phát triển hay được kỹ nghệ hoá và được chế tạo tương tự như các sản phẩm công nghiệp (phần cứng) khác. Phát triển phần mềm và chế tạo phần cứng cũng có những điểm tương đồng: đều là sản phẩm và chất lượng của chúng phụ thuộc nhiều vào thiết kế, hơn nữa lại phụ thuộc cơ bản vào con người. Tuy nhiên phần mềm và phần cứng lại có nhiều điểm đặc trưng rất khác nhau. Qui trình và phương pháp tổ chức thực hiện để sản xuất ra chúng rất khác nhau, Các giai đoạn chế tạo ra phần cứng có thể xác định và có khả năng điều chỉnh được chất lượng của sản phẩm còn đối với phần mềm thì không dễ gì thay đổi được, Mối quan hệ giữa người sử dụng và công việc cần thực hiện với từng loại sản phẩm là hoàn toàn khác nhau, Cách tiếp cận để xây dựng, chế tạo các sản phẩm cũng khác nhau. Khả năng nhân bản của chúng là hoàn toàn trái ngược nhau. Việc bảo vệ bản quyền sản phẩm phần mềm là cực kỳ khó khăn vì khả năng sao chép thành nhiều bản giống nhau là có thể thực hiện được (tương đối dễ). Phần mềm khác hẳn với phần cứng là không bị hư hỏng theo thời gian, không bị tác động của môi trường (thời tiết, nhiệt độ, điều kiện, v.v ). Do vậy, đối với phần cứng việc bảo hành là đảm bảo nó hoạt động được như mới còn đối với phần mềm thì lại khác hẳn. Bảo hành, bảo trì phần mềm là bảo đảm cho hệ thống hoạt động đúng với thiết kế và đáp ứng yêu cầu sử dụng của khách - 37 -
hàng. Chính vì thế mà công bảo hành phần mềm là rất tốn kém và đòi hỏi phải tập trung nhiều hơn vào khâu phân tích, thiết kế hệ thống. Mọi hệ thống phần mềm cũng như các hệ thống khác không thể tồn tại độc lập mà nó luôn hoạt động và tồn tại trong một môi trường, tương tác với thế giới xung quanh. Như vậy một hệ thống có thể xem như là hệ thống con của một hệ thống khác và bản thân nó lại có thể chứa một số các hệ thống con khác nhỏ hơn. Công nghệ phần cứng phát triển nhanh cả về chất lượng và tốc độ xử lý với giá thành ngày một hạ trong khi giá phần mềm lại rất cao. Để phát triển được những hệ thống phần mềm đáp ứng được những yêu cầu trên thì đòi hỏi phải áp dụng lý thuyết, kỹ nghệ, phương pháp và công cụ mới để tạo ra một qui trình phát triển phần mềm thống nhất. Như vậy, công nghệ phần mềm (CNPM) là đề cập đến các lý thuyết, phương pháp luận và các công cụ cần thiết để phát triển phần mềm. Mục đích của CNPM là làm ra những phần mềm chất lượng cao, tin cậy với một hạn chế về nguồn lực, theo đúng một lịch trình đặt trước, phù hợp với ngân sách dự kiến và đáp ứng các yêu cầu người dùng. Hơn nữa, CNPM không chỉ là phải làm ra hệ thống phần mềm mà phải làm được các hồ sơ, tài liệu như các tài liệu thiết kế, tài liệu hướng dẫn sử dụng, v.v. làm cơ sở để bảo trì và mở rộng, phát triển hệ thống sau này. Tóm lại để xây dựng được những hệ thống phần mềm đáp ứng những yêu cầu trên, chúng ta cần phải: . Có một qui trình phát triển phần mềm thống nhất gồm các bước thực hiện rõ ràng, mà sau mỗi bước đều phải có các sản phẩm cụ thể; . Có các phương pháp và kỹ nghệ phù hợp với từng pha thực hiện phát triển phần mềm; . Có công cụ để làm ra sản phẩm phần mềm theo yêu cầu. Quá trình phát triển một sản phẩm (Product Development Process) là quá trình định nghĩa ai làm cái gì, làm khi nào và như thế nào. Quá trình xây dựng một sản phẩm phần mềm hoặc nâng cấp một sản phẩm đã có được gọi là quá trình phát triển phần mềm (Software Development Process). Hệ thống phần mềm được kiến tạo là sản phẩm của một loạt các hoạt động sáng tạo và có quá trình phát triển. Quá trình phát triển những phần mềm phức tạp phải có nhiều người tham gia thực hiện. Trước hết đó là khách hàng và những nhà đầu tư, đó là những người đưa ra vấn đề cần giải quyết trên máy tính. Những người phát triển hệ thống gồm các nhà phân tích, thiết kế và lập trình làm nhiệm vụ phân tích các yêu cầu của khách hàng, thiết kế các thành phần của hệ thống và thực thi cài đặt chúng. Sau đó phần mềm được kiểm tra (Testing) và triển khai ứng dụng để thực thi những vấn đề mà người sử dụng yêu cầu. Quá trình phát triển phần mềm được xác định thông qua tập các hoạt động cần thực hiện để chuyển đổi các yêu cầu của khách hàng (người sử dụng) thành hệ thống phần mềm. Có năm bước chính cần thực hiện trong quá trình phát triển phần mềm: 1. Xác định các yêu cầu 2. Phân tích hệ thống - 38 -
3. Thiết kế hệ thống 4. Lập trình và kiểm tra hệ thống 5. Vận hành và bảo trì hệ thống. Có thể thực hiện các bước trên theo nhiều phương pháp khác nhau. Theo đó, số các bước đề xuất của các phương pháp cũng có thể khác nhau. Các dự án có thể thực hiện theo những mô hình khác nhau (([3], [12]) như mô hình "thác nước" (waterfall), mô hình "tạo nguyên mẫu" (Prototype), mô hình "xoắn ốc", v.v. tuỳ thuộc vào từng dự án khác nhau. Như ở chương 1 đã phân tích, có hai cách tiếp cận chính để thực hiện các bước nêu trên: cách tiếp cận hướng chức năng và hướng đối tượng. Ở đây chúng ta tập trung nghiên cứu các phương pháp phân tích và thiết kế hướng đối tượng. 2.6.1 Xác định các yêu cầu và phân tích hệ thống Phân tích các yêu cầu của hệ thống Từ các yêu cầu của khách hàng chúng ta xác định được các mục tiêu của phần mềm cần phát triển. Thường đó là các yêu cầu chức năng về những gì mà hệ thống phải thực hiện, nhưng chưa cần chỉ ra các chức năng đó thực hiện như thế nào. Việc xác định đúng và đầy đủ các yêu cầu của bài toán là nhiệm vụ rất quan trọng, nó làm cơ sở cho tất cả các bước tiếp trong dự án phần mềm. Muốn vậy, thì phải đặc tả được các yêu cầu của hệ thống. UML cung cấp biểu đồ ca sử dụng để đặc tả các yêu cầu của hệ thống Tài liệu đặc tả các yêu cầu được sử dụng để: . Làm cơ sở để trao đổi với người sử dụng, để thảo luận giữa các nhóm thành viên trong dự án phát triển phần mềm về những gì mà hệ thống sẽ phải thực hiện (và những gì nó không cần thực hiện). . Làm căn cứ cơ bản cho các bước tiếp theo trong quá trình phát triển phần mềm. Muốn đạt được các mục tiêu trên thì quá trình phải thực hiện: . Hiểu rõ miền xác định của bài toán (Domain Understanding): Những người phát triển sẽ xây dựng hệ thống theo sự hiểu biết của họ như thế nào về những yêu cầu của khách hàng và những khái niệm cơ sở của bài toán ứng dụng. . Nắm bắt các yêu cầu (Requirement Capture): Người phân tích phải nắm bắt được tất cả các nhu cầu của khách hàng bằng cách phải trao đổi với mọi người có liên quan đến dự án, tham khảo các tài liệu liên quan. Thông qua việc thảo luận, trao đổi với khách hàng, các chuyên gia của lĩnh vực ứng dụng và những người đã, đang sử dụng những hệ thống có sẵn ta có thể phát hiện và nắm bắt được các yêu cầu của họ. Phương pháp trừu tượng hoá giúp ta dễ dàng nắm bắt được các yêu cầu của hệ thống. . Phân loại (Classification): Vấn đề quan trọng nhất trong giai đoạn này là phải hiểu rõ các yêu cầu đã được xác định. Muốn vậy, ta phải tìm cách phân loại chúng theo tầm quan trọng, hay chức năng chính của những người sử dụng và của khách hàng. - 39 -
. Thẩm định (Validation): Kiểm tra xem các yêu cầu có thống nhất với nhau và đầy đủ không, đồng thời tìm cách giải quyết các mối mâu thuẫn giữa các yêu cầu nếu có. . Nghiên cứu tính khả thi (Feasibility Study): Tính khả thi của một dự án tin học phải được thực hiện dựa trên các yếu tố bao gồm các khía cạnh tài chính, chiến lược, thị trường, con người, đối tác, kỹ thuật, công nghệ và phương pháp mô hình hoá, v.v. Nói chung không có các qui tắc hướng dẫn cụ thể để biết khi nào công việc phân tích các yêu cầu sẽ kết thúc và quá trình phát triển có thể chuyển sang bước tiếp theo. Nhưng có thể dựa vào các câu trả lời cho những câu hỏi sau để chuyển sang bước tiếp theo. . Khách hàng, người sử dụng (NSD) và những người phát triển đã hiểu hoàn toàn hệ thống chưa? . Đã nêu được đầy đủ các yêu cầu về chức năng (dịch vụ), đầu vào / ra và những dữ liệu cần thiết chưa? Bức tranh chung trong pha phân tích các yêu cầu của hệ thống có thể mô tả như trong hình 2-22. Người phát triển hệ thống Hiểu rõ Nắm bắt các yêu cầu các yêu cầu Khách hàng, Nghiên cứu Mô tả Các chuyên gia tính khả thi hệ thống các yêu cầu Thẩm Phân định loại Người sử dụng (NSD) Tài liệu đặc tả yêu cầu và bước tiếp theo Hình 2-22 Mối quan hệ giữa các công việc trong pha phân tích các yêu cầu Vấn đề xác định đúng và đầy đủ các yêu cầu của hệ thống là rất quan trọng, nó ảnh hưởng rất lớn tới chất lượng của sản phẩn sau này. Theo Finkelstein (1989) khi khảo sát, đánh giá về các pha thực hiện trong quá trình phát triển phần mềm thì trên 55% [10] các lỗi của phần mềm là do các yêu cầu của hệ thống chưa được phát hiện đầy đủ và chi phí cho việc sửa các lỗi đó ( để bảo trì hệ thống) chiếm tới trên 80% chi phí của cả dự án. - 40 -
2.6.2 Phân tích hệ thống hướng đối tượng Phân tích hướng đối tượng (Object Oriented Analysis - OOA): là một giai đoạn của quá trình phát triển phần mềm, trong đó mô hình khái niệm được mô tả chính xác, súc tích thông qua các đối tượng thực và các khái niệm của bài toán ứng dụng. Phân tích hướng đối tượng vừa là ngành khoa học vừa là nghệ thuật nên để xây dựng được những hệ thống tốt, tráng kiện (Robust), có tính mở và dễ bảo trì thì ta phải biết vận dụng các nguyên lý, phương pháp khoa học kết hợp được cả heuristic và các mẫu thử nghiệm (Patterns) để nhanh chóng tích luỹ và hoàn thiện kỹ năng phân tích, thiết kế của mình. Thông qua việc áp dụng các nguyên lý và kinh nghiệm thực hiện theo mẫu hướng dẫn [4] chúng ta nhanh chóng học được cách tạo ra các thiết kế hệ thống phần mềm tốt hơn. Phân tích hướng đối tượng tập trung vào việc tìm kiếm các đối tượng, khái niệm trong lĩnh vực bài toán và xác định mối quan hệ của chúng trong hệ thống. Nhiệm vụ của người phân tích là nghiên cứu kỹ các yêu cầu của hệ thống và phân tích các thành phần của hệ thống cùng các mối quan hệ của chúng. Trong khâu phân tích hệ thống chủ yếu trả lời câu hỏi: . Hệ thống gồm những thành phần, bộ phận nào? . Hệ thống cần thực hiện những cái gì? Kết quả chính của pha phân tích hệ thống hướng đối tượng là biểu đồ lớp, biểu đồ trạng thái, biểu đồ trình tự, biểu đồ cộng tác và biểu đồ thành phần. 2.6.3 Thiết kế hệ thống hướng đối tượng Dựa vào các đặc tả yêu cầu và các kết quả phân tích (các biểu đồ nêu trên) để thiết kế hệ thống. Thiết kế hướng đối tượng (Object Oriented Design – OOD) là một giai đoạn trong quá trình phát triển phần mềm, trong đó hệ thống được tổ chức thành tập các đối tượng tương tác với nhau và mô tả được cách để hệ thống thực thi nhiệm vụ của bài toán ứng dụng. Trong khâu thiết kế hệ thống hướng đối tượng chủ yếu trả lời câu hỏi làm như thế nào: . Trong hệ thống có những lớp đối tượng nào, trách nhiệm của chúng là gì? . Các đối tượng tương tác với nhau như thế nào? . Các nhiệm vụ mà mỗi lớp đối tượng phải thực hiện? . Dữ liệu nghiệp vụ và các giao diện được xây dựng như thế nào? . Kiến trúc và cấu hình của hệ thống? Nhiệm vụ chính của thiết kế hệ thống là: . Xây dựng các thiết kế chi tiết mô tả các thành phần của hệ thống ở mức cao hơn (khâu phân tích) để phục vụ cho việc cài đặt. Nghĩa là, các lớp đối tượng được định nghĩa chi tiết gồm đầy đủ các thuộc tính, các thao tác phục vụ cho việc cài đặt bằng ngôn ngữ lập trình hướng đối tượng được lựa chọn ở các bước sau. - 41 -
. Đồng thời đưa ra được kiến trúc (là trọng tâm) của hệ thống để đảm bảo cho hệ thống có thể thay đổi, có tính mở, dễ bảo trì, thân thiện với NSD, v.v. Nghĩa là tổ chức các lớp thành các gói hoặc các hệ thống con theo một kiến trúc phù hợp với nhu cầu phát triển của công nghệ (mạng, phân tán, v.v.) đồng thời phù hợp với xu thế phát triển của lĩnh vực ứng dụng. Những kết quả trên được thể hiện trong các biểu đồ: biểu đồ lớp (chi tiết), biểu đồ hành động, biểu đồ thành phần và biểu đồ triển khai. Tất cả các kết quả thiết kế phải được ghi lại thành các hồ sơ, tài liệu cho hệ thống. Trong các tài liệu thiết kế phải mô tả cụ thể những thành phần nào, làm những gì và làm như thế nào. Mô hình khái niệm, Kiến trúc chi tiết, cụ thể và Đặc tả các yêu cầu phụ thuộc vào vài đặt: khung của hệ thống Thiết kế logic: Kiến trúc tổng quát Thiết kế chi tiết: Phân chia các thành phần, độc lập và trừu tượng Làm mịn dần các thành phần, Nhiệm vụ của mỗi thành Cách thực hiện của mỗi thành phần phần Thiết kế các mối quan hệ Quan hệ giữa các thành Hình 2-23 Thiết kế logic và thiết kế chi tiết 2.6.4 Lập trình và kiểm tra chương trình Trong giai đoạn này, mỗi thành phần đã được thiết kế sẽ được lập trình thành những mô đun chương trình (chương trình con). Mỗi mô đun này sẽ được kiểm chứng hoặc thử nghiệm theo các tài liệu đặc tả của giai đoạn thiết kế. Công việc này được mô tả như sau: Tập các mô đun Đặc tả thiết kế Lập trình chương trình và kiểm thử chương trình Hình 2-24 Lập trình và kiểm tra chương trình Sau đó các mô đun chương trình đã được kiểm tra, được tích hợp với nhau thành hệ thống tổng thể và nó sẽ được kiểm tra xem có đáp ứng được các yêu cầu của khách hàng hay không. Kết thúc pha này là phần mềm cần phải xây dựng. Hiện nay có một số công cụ hỗ trợ cho quá trình phân tích, thiết kế và có thể sinh mã tự động cho những thành phần chính của mô hình như: Rose [8], hay Visual Studio .NET của Microsoft, v.v. - 42 -
2.6.5 Vận hành và bảo trì hệ thống Giai đoạn này bắt đầu bằng việc cài đặt hệ thống phần mềm trong môi trường sử dụng của khách hàng sau khi sản phẩm đã được giao cho họ. Hệ thống sẽ hoạt động, cung cấp các thông tin, xử lý các yêu cầu và thực hiện những gì đã được thiết kế. Tuy nhiên vấn đề bảo trì phần mềm hoàn toàn khác với bảo trì của phần cứng. Như đã phân tích ở trên, bảo trì phần mềm là đảm bảo cho hệ thống hoạt động đáp ứng được các yêu cầu của NSD, của khách hàng. Mà các yêu cầu này trong thực tế lại hay thay đổi, do vậy công tác bảo trì lại bao gồm cả những sự thay đổi hệ thống sao cho nó phù hợp với yêu cầu hiện tại của họ, thậm chí có những thay đổi chưa phát hiện được trong các pha phân tích, thiết kế. Nghĩa là hệ thống phần mềm phải được nâng cấp, hoàn thiện liên tục và chi phí cho công tác bảo trì là khá tốn kém. Thông thường, có hai loại nâng cấp: . Nâng cao hiệu quả của hệ thống: bao gồm những thay đổi mà khách hàng cho là sẽ cải thiện hiệu quả công việc của hệ thống, như bổ sung thêm các chức năng hay giảm thời gian xử lý, trả lời của hệ thống, v.v. . Đảm bảo sự thích nghi đối với sự thay đổi của môi trường của hệ thống hay sự sửa đổi cho phù hợp với những thay đổi của chính sách, qui chế mới ban hành của Chính phủ. Tóm lại, thực hiện phân tích và thiết kế hướng đối tượng bằng UML là xây dựng các biểu đồ mô tả các yêu cầu, khái niệm và kiến trúc của hệ thống. Quá trình xây dựng các biểu đồ đó có thể thực hiện như trong hình 2-25. Bi ểu đồ ca sử dụng Biểu đồ trình tự Biểu đồ cộng tác Biểu đồ trạng thái Biểu đồ lớp Biểu đồ hành động Biểu đồ triển khai Biểu đồ thành phần - 43 -
Hình 2-25 Qui trình xây dựng các biểu đồ UML trong phân tích, thiết kế hệ thống Chi tiết về các biểu đồ và cách xây dựng chúng như thế nào sẽ được đề cập ở các chương sau. 2.7 Rational Rose và quá trình phát triển phần mềm thống nhất Rational Rose [8] là phần mềm công cụ mạnh hỗ trợ cho quá trình phân tích, thiết kế hệ thống hướng đối tượng. Nó giúp cho việc mô hình hoá hệ thống trước khi viết chương trình, đồng thời có khả năng kiểm tra đảm bảo tính đúng đắn, hợp lý của kiến trúc hệ thống từ khi khởi đầu dự án. . Rose hỗ trợ để xây dựng các biểu đồ UML mô hình hoá các lớp, các thành phần và mối quan hệ của chúng trong hệ thống một cách trực quan và thống nhất. . Nó cho phép mô tả chi tiết hệ thống bao gồm những cái gì, trao đổi tương tác với nhau và hoạt động như thế nào để người phát triển hệ thống có thể sử dụng mô hình như kế hoặch chi tiết cho việc xây dựng hệ thống. . Rose còn hỗ trợ rất tốt trong giao tiếp với khách hàng và làm hồ sơ, tài liệu cho từng phần tử trong mô hình. . Rose hỗ trợ cho việc chuyển bản thiết kế chi tiết sang mã chương trình trong một ngôn ngữ lập trình lựa chọn và ngược lại, mã chương trình có thể chuyển trở lại yêu cầu hệ thống. Rose hỗ trợ phát sinh mã khung chương trình trong nhiều ngôn ngữ lập trình khác nhau như: C++, Java, Visual Basic, Oracle 8, v.v. Ngoài ra Rose hỗ trợ cho các nhà phân tích, thiết kế và phát triển phần mềm: . Tổ chức mô hình hệ thống thành một hay nhiều tệp, được gọi là đơn vị điều khiển được (Controlled Unit). Cho phép phát triển song song các đơn thể điều khiển được của mô hình, . Cho phép sao chép hay chuyển dịch các tệp mô hình, các đơn vị điều khiển được giữa các không gian làm việc khác nhau theo cơ chế “ánh xạ đường dẫn ảo” (Virtual Path Map), . Cho phép quản lý mô hình và tích hợp với những hệ thống điều khiển chuẩn, Rose cung cấp khả năng tích hợp với ClearCase và Microsoft Visual SourceSafe, v.v. . Sử dụng các bộ tích hợp mô hình (Model Integator) để so sánh và kết hợp các mô hình, các đơn vị điều khiển được với nhau. Bản thân UML không định nghĩa quá trình phát triển phần mềm, nhưng UML và Rose hỗ trợ rất hiệu quả trong cả quá trình xây dựng phần mềm. - 44 -
Bài tập và câu hỏi 2.1 Vai trò của UML trong mô hình hoá hệ thống? 2.2 Có bao nhiêu loại biểu đồ, nêu tóm tắt nhiệm vụ của các biểu đồ. 2.3 Nêu những khái niệm cơ sở của phương pháp hướng đối tượng và các ký hiệu của chúng trong UML. 2.4 Quá trình phát triển phần mềm là gì, nêu các pha chính cần thực hiện theo cách tiếp cận hướng đối tượng. 2.5 Tìm hiểu vai trò của Rational Rose trong quá trình phát triển phần mềm thống nhất. 2.6 Chọn từ danh sách dưới đây những thuật ngữ thích hợp để điền vào các chỗ [( )] trong đoạn văn mô tả về ngôn ngữ mô hình hoá UML. UML là ngôn ngữ mô hình hoá, trước hết nó mô tả [(1)], ngữ nghĩa các định nghĩa trực quan tất cả các thành phần của [(2)]. UML được sử dụng để hiển thị, đặc tả, tổ chức, xây dựng và [(3)] các vật phẩm (artifacts) của [(4)], đặc biệt là phân tích, thiết kế dưới dạng các báo cáo, biểu đồ, bản mẫu hay các trang web, v.v. UML là ngôn ngữ [(2)] hoá độc lập với các công nghệ phát triển [(5)]. Chọn câu trả lời: a. quá trình phát triển phần mềm hướng đối tượng b. quá trình xử lý c. mô hình d. ký pháp thống nhất e. phần mềm 2.7 Chọn từ danh sách dưới đây những thuật ngữ thích hợp để điền vào các chỗ [( )] trong đoạn văn mô tả về khái niệm lớp. Đối tượng là một thể hiện của một [(1)]. Lớp là một mô tả về một nhóm các đối tượng có những [(2)], có chung các [(3)], có [(4)] với các đối tượng của các lớp khác và có chung ngữ nghĩa trong hệ thống. [(1)] chính là cơ chế được sử dụng để phân loại các đối tượng của một hệ thống. Lớp thường xuất hiện dưới dạng những [(5)] trong các tài liệu mô tả bài toán hay trong các thảo luận với người sử dụng. Cũng như các đối tượng, lớp có thể là những nhóm các thực thể có trong thế giới thực, cũng có những lớp là khái niệm trừu tượng và có những lớp được đưa vào trong thiết kế để phục vụ cho cài đặt hệ thống, v.v. Chọn câu trả lời: a. hành vi ứng xử b. cùng mối quan hệ - 45 -
c. lớp d. tính chất (thuộc tính) giống nhau e. danh từ chung CHƯƠNG III BIỂU ĐỒ CA SỬ DỤNG PHÂN TÍCH CÁC NHU CẦU CỦA HỆ THỐNG Chương III giới thiệu:  Xác định nhu cầu của bài toán ứng dụng,  Các thành phần của biểu đồ ca sử dụng: ca sử dụng, tác nhân ngoài,  Phương pháp xác định, phân tích các yêu cầu của hệ thống và biểu đồ ca sử dụng,  Cách xây dựng biểu đồ ca sử dụng để đặc tả các yêu cầu. 3.1 Định nghĩa bài toán Đây là bước mở đầu của quá trình phát triển hệ thống, nhiệm vụ chủ yếu là xác định các nhu cầu của bài toán. “Nhu cầu là mẹ của mọi sáng tạo”, cho nên để sáng tạo ra một hệ thống mới, người phát triển trước hết phải làm quen, thâm nhập vào chuyên môn, nghiệp vụ mà hệ thống đó phải đáp ứng và tìm hiểu, tập hợp các nhu cầu của hệ thống. Sau đây chúng ta định nghĩa bài toán làm cơ sở để mô tả cách thực hiện phân tích và thiết kế hệ thống phần mềm hướng đối tượng. Bài toán được mô tả như sau: Bài toán: “Một Công ty muốn xây dựng Hệ thống phần mềm để phục vụ và quản lý các hoạt động kinh doanh, bán hàng. Công ty có nhiều điểm bán hàng đầu cuối (POST: Point Of Sale Terminal) đó là những cửa hàng siêu thị, do vậy hệ thống cần phải ghi nhận các hoạt động bán hàng và xử lý các công việc thanh toán với khách hàng, chủ yếu khách hàng mua lẻ. Ngoài ra hệ thống còn giúp Giám đốc Công ty theo dõi được các hoạt động kinh doanh, tự động kiểm kê các mặt hàng tồn đọng trong kho, các mặt hàng bán chạy, v.v. để hỗ trợ ra quyết định trong các hoạt động kinh doanh của Công ty. Trong mỗi cửa hàng đầu cuối đều có các thiết bị phần cứng như: máy tính, máy đọc mã vạch ( bar code scanner) và phần mềm hệ thống để chạy hệ thống sẽ được xây dựng”. Hệ thống bán hàng viết tắt là HBH, là chương trình phần mềm được sử dụng để ghi lại các phiên bán hàng, xử lý và thanh toán nhanh với khách hàng, chủ yếu là phục vụ khách hàng mua lẻ. Thông thường thì một hệ thống mới được xây dựng là nhằm để thay thế cho - 46 -
một hệ thống cũ đã bộc lộ nhiều điều bất cập. Chính vì thế mà việc tìm hiểu nhu cầu với hệ thống mới thường bắt đầu từ việc khảo sát và đánh giá hệ thống cũ. Mục đích của HBH . Tăng nhanh hoặc tự động hoá việc bán hàng, ghi nhận các mặt hàng: loại sản phẩm, mô tả sản phẩm, số lượng và xác định giá bán, tính tiền, v.v., đáp ứng mọi yêu cầu của khách hàng, . Thanh toán nhanh với khách hàng bằng các phương thức: tiền mặt, thẻ tín dụng (Credit Card), hay séc (Check), . Phân tích, xử lý các kết quả bán hàng nhanh và chính xác để hỗ trợ quyết định trong các hoạt động kinh doanh, . Thực hiện tự động kiểm kê các mặt hàng trong kho, theo dõi được những mặt hàng bán chạy, những mặt hàng tồn kho để có được những quyết định kịp thời trong kinh doanh. Tóm lại, hệ thống xây dựng nhằm tự động hoá các hoạt động kinh doanh, phục vụ khách hàng nhanh hơn, tốt hơn và rẻ hơn. Các chức năng, nhiệm vụ của hệ thống Chức năng của hệ thống là những gì mà hệ thống được yêu cầu thực hiện. Nhiệm vụ “X” sẽ là chức năng của hệ thống nếu trong mô tả bài toán có mệnh đề dạng: Hệ thống phải thực hiện X. Tất nhiên trong giai đoạn này, các tính chất, các yêu cầu về chất lượng hệ thống như tính hiệu quả, an toàn hệ thống chưa được xem là chức năng của hệ thống, nghĩa là chưa xét tới các đặc tính phi chức năng của hệ thống. Các chức năng của hệ thống có thể phân loại thành các phạm trù theo các lĩnh vực chức năng hay theo những mức ưu tiên khác nhau để loại trừ sự lẫn lộn giữa chúng. Các chức năng hệ thống có thể chia thành: . Những chức năng hiển (Evident): Những chức năng cần thực hiện và NSD có thể nhận biết, theo dõi được sự hoạt động của chúng. Ví dụ: khi người bán nhập các mặt hàng mà khách đã chọn mua ở trong giỏ hàng vào hệ thống thì mọi thông tin liên quan đến tên gọi sản phẩm, số lượng, giá bán, v.v. đều phải được hiện lên màn hình và khách hàng có thể theo dõi một cách tường minh. . Những chức năng ẩn (hiddent): Những chức năng cần thực hiện và NSD không theo dõi được. Thường đó là những chức năng kỹ thuật như những công việc tổ chức lưu trữ, xử lý dữ liệu để đảm bảo sự bền vững dữ liệu trong các CSDL. Ví dụ: sau mỗi phiên bán hàng, nghĩa là sau khi khách đã trả đủ tiền mua hàng, hệ thống bán hàng HBH phải thực hiện cập nhật lại số lượng của những mặt hàng vừa bán được. Những hoạt động này NSD không theo dõi được. - 47 -
. Một số chức năng tuỳ chọn (optional): Những chức năng có thể bổ sung tăng thêm mức độ thân thiện, tiện dụng cho hệ thống nhưng không ảnh hưởng tới giá trị cũng như các chức năng khác của hệ thống. Các chức năng của hệ thống phải được chia thành các nhóm theo các mối liên hệ cố kết với nhau. Dựa vào cách phân chia các chức năng để sau này chia nhỏ hệ thống thành các gói, các hệ thống con trong quá trình phân tích và thiết kế hệ thống. Ví dụ: Các chức năng của hệ thống HBH có thể chia thành hai nhóm chính: các chức năng bán hàng (các chức năng cơ sở) và các chức năng thanh toán. Dựa trên những kết quả khảo sát bài toán bán hàng, nghiên cứu các sổ sách, tài liệu và trên cơ sở trao đổi với những người bán hàng, với khách hàng, v.v. chúng ta xác định được các chức năng chính của hệ thống như sau: Qui tắc # Chức năng Loại R1.1 Ghi nhận các mặt hàng ở trong giỏ hàng mà khách hàng đã chọn. Hiển R1.2 Tính tổng số tiền bán cho khách hàng đang mua. Hiển R1.3 Nhập các thông tin về các mặt hàng qua mã vạch bằng máy đọc Hiển mã vạch hoặc nhập mã sản phẩm (UPC – Universal Product Code) trực tiếp từ bàn phím. R1.4 Cập nhật, trừ bớt số lượng đã bán sau từng phiên bán hàng. Ẩn R1.5 Kết thúc một phiên bán hàng. Ẩn R1.6 Người bán hàng (cashier) phải login để khởi động hệ thống (cho Hiển biết tên ID và password) để sử dụng hệ thống. R1.7 Cung cấp một cơ chế lưu trữ nhất quán, CSDL. Ẩn R1.8 Cung cấp cơ chế trao đổi giữa các tiến trình, trao đổi thông tin Ẩn giữa các hệ thống với nhau. R1.9 Hiển thị các thông tin mô tả và giá bán các mặt hàng để khách Hiển hàng có thể theo dõi được. Những chức năng thực hiện thanh toán với khách hàng. Qui tắc # Chức năng Loại R2.1 Thu tiền mặt, nhập số tiền khách đưa và tính số dư phải trả lại Hiển cho khách hàng. R2.2 Thu tiền bằng thẻ tín dụng (Credit), nhập thông tin của thẻ tín Hiển dụng của khách qua máy đọc thẻ hoặc nhập trực tiếp từ bàn phím. R2.3 Thu tiền bằng séc, nhập số hiệu và số tiền của tờ Check, tính số Hiển dư phải trả lại cho khách. - 48 -