›
›

Bài giảng môn Phân tích và thiết kế hệ thống hướng đối tượng

pdf 52 trang ngocly 80
Download
Bạn đang xem 20 trang mẫu của tài liệu "Bài giảng môn Phân tích và thiết kế hệ thống hướng đối tượng", để 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:

  • pdfbai_giang_mon_phan_tich_va_thiet_ke_he_thong_huong_doi_tuong.pdf

Nội dung text: Bài giảng môn Phân tích và thiết kế hệ thống hướng đối tượng

  1. 1 TRƢỜNG ĐẠI HỌC HÀNG HẢI VIỆT NAM KHOA CÔNG NGHỆ THÔNG TIN BỘ MÔN HỆ THỐNG THÔNG TIN BÀI GIẢNG PHÂN TÍCH & THIẾT KẾ HỆ THỐNG HƢỚNG ĐỐI TƢỢNG TÊN HỌC PHẦN : PHÂN TÍCH & THIẾT KẾ HỆ THỐNG HƢỚNG ĐỐI TƢỢNG MÃ HỌC PHẦN : 17407 TRÌNH ĐỘ ĐÀO TẠO : ĐẠI HỌC CHÍNH QUY DÙNG CHO SV NGÀNH : CÔNG NGHỆ THÔNG TIN HẢI PHÒNG - 2011
  2. 2 MỤC LỤC Nội dung Trang Chƣơng 1. Mô hình đối tƣợng 5 1.1. Sự phát triển của mô hình đối tượng 5 1.2. Nền tảng của mô hình đối tượng 8 1.3. Phần tử cơ bản trong mô hình đối tượng 9 Chƣơng 2. Lớp và đối tƣợng 12 2.1. Cơ bản về đối tượng 12 2.2. Mối quan hệ giữa các đối tượng 12 2.3. Cơ bản về lớp 13 2.4. Mối quan hệ giữa các lớp 15 2.5. Sự tương tác lẫn nhau của lớp và đối tượng 15 Chƣơng 3. Sự phân loại (Classification). 16 3.1. Tầm quan trọng của sự phân loại 16 3.2. Xác định các lớp và đối tượng 16 Chƣơng 4. Phân tích thiết kế hệ thống hƣớng đối tƣợng sử dụng UML (Unified 18 Model Language) 4.1. Ngôn ngữ mô hình thống nhất (UML) 18 4.2. Các biểu đồ (Diagrams) 23 Chƣơng 5. Quy trình phân tích và thiết kế 37 5.1. Nền tảng 37 5.2. Quy trình vĩ mô: Vòng đời của triển khai phần mềm 37 5.3. Quy trình vi mô: Quá trình phân tích và thiết kế 40 Chƣơng 6. Một số bài toán cụ thể 44 6.1. Hệ thống điều khiển: Quản lý hệ thống giao thông 44 6.2. Ứng dụng mạng lưới: Hệ thống theo dõi kỳ nghỉ 46
  3. 3 Tên học phần: Phân tích & Thiết kế hệ thống hướng đối tượng Loại học phần: 2 Bộ môn phụ trách giảng dạy: Hệ thống Thông tin Khoa phụ trách: CNTT. Mã học phần: 17407 Tổng số TC: 2 TS tiết Lý thuyết Thực hành/ Xemina Tự học Bài tập lớn Đồ án môn học 45 30 15 0 0 0 Học phần học trƣớc: Phân tích và Thiết kế hệ thống Học phần tiên quyết: Không yêu cầu. Học phần song song: Không yêu cầu. Mục tiêu của học phần: Cung cấp các kiến thức cơ bản về phân tích, thiết kế hệ thống thông tin tin học hoá theo mô hình hướng đối tượng sử dụng UML. Nội dung chủ yếu: Phương pháp luận phân tích thiết kế hệ thống hướng đối tượng; Nguyên tắc và công cụ mô hình hoá hệ thống; Thiết kế và cài đặt hệ thống hướng đối tượng; Các ví dụ minh hoạ. Nội dung chi tiết: PHÂN PHỐI SỐ TIẾT TÊN CHƢƠNG MỤC TS LT TH BT KT Chƣơng 1. Mô hình đối tƣợng 2 2 1.1. Sự phát triển của mô hình đối tượng 1.2. Nền tảng của mô hình đối tượng 1.3. Phần tử cơ bản trong mô hình đối tượng Chƣơng 2. Lớp và đối tƣợng 2 2 2.1. Cơ bản về đối tượng 2.2. Mối quan hệ giữa các đối tượng 2.3. Cơ bản về lớp 2.4. Mối quan hệ giữa các lớp 2.5. Sự tương tác lẫn nhau của lớp và đối tượng Chƣơng 3. Sự phân loại (Classification). 2 3.1. Tầm quan trọng của sự phân loại 3.2. Xác định các lớp và đối tượng Chƣơng 4. Phân tích thiết kế hệ thống hƣớng đối 18 16 2 tƣợng sử dụng UML (Unified Model Language) 4.1. Ngôn ngữ mô hình thống nhất (UML) 4.2. Các biểu đồ (Diagrams) Chƣơng 5. Quy trình phân tích và thiết kế 2 2 5.1. Nền tảng 5.2. Quy trình vĩ mô: Vòng đời của triển khai phần mềm 5.3. Quy trình vi mô: Quá trình phân tích và thiết kế Chƣơng 6. Một số bài toán cụ thể 4 3 1 6.1. Hệ thống điều khiển: Quản lý hệ thống giao thông 6.2. Ứng dụng mạng lưới: Hệ thống theo dõi kỳ nghỉ Nhiệm vụ của sinh viên: Tham dự các buổi học lý thuyết và thực hành, làm các bài tập được giao, làm các bài thi giữa học phần và bài thi kết thúc học phần theo đúng quy định. Tài liệu học tập: 1. Grady Booch, Robert A.Maksimchuk, Michael W.Engle, Bobbi J.Young, Ph.D, Jim Conallen, Kelli A.Houston, Object-Oriented Analysis And Design with Application, Third Edition. 2. Robert V. Stumpf, Lavette C. Teague, Object-Oriented Systems Analysis and Design with UML, Pearson Prentice Hall 3. Đoàn Văn Ban, Phân tích và thiết kế hệ thống hướng đối tượng, Nhà xuất bản ĐHQG Hà Nội, 2006.
  4. 4 4. Nguyễn Văn Vỵ, Phân tích và thiết kế các hệ thống thông tin hiện đại, Nhà xuất bản Thống Kê, Hà Nội, 2002. Hình thức và tiêu chuẩn đánh giá sinh viên: - Hình thức thi: thi viết. - Tiêu chuẩn đánh giá sinh viên: căn cứ vào sự tham gia học tập của sinh viên trong các buổi học lý thuyết và thực hành, kết quả làm các bài tập được giao, kết quả của các bài thi giữa học phần và bài thi kết thúc học phần. Thang điểm: Thang điểm chữ A, B, C, D, F. Điểm đánh giá học phần: Z = 0,3X + 0,7Y. Bài giảng này là tài liệu chính thức và thống nhất của Bộ môn Hệ thống Thông tin, Khoa Công nghệ Thông tin và được dùng để giảng dạy cho sinh viên. Ngày phê duyệt: / / Trƣởng Bộ môn
  5. 5 CHƢƠNG I: MÔ HÌNH ĐỐI TƢỢNG 1.1. Sự phát triển của mô hình đối tượng Trong mục này chúng ta khảo sát sự phát triển của các công cụ để giúp chúng ta hiểu sự thành lập và các nét nổi bật của kỹ thuật hướng đối tượng. Trong quá trình phát triển công nghệ phần mềm chúng ta có thể để ý và nghiên cứu theo 2 hướng sau: - Phát triển các chương trình nhỏ tới các chương trình lớn - Sự phát triển của các ngôn ngữ lập trình bậc cao hơn. Hầu hết tất cả các chương trình phần mềm ngày càng đòi hỏi cao vào phức tạp hơn. Chính điều này đã thúc đẩy việc nghiên cứu trong lĩnh vực công nghệ phần mềm, mà đặc biệt quan tâm tới sự phân tích, trừu tượng và tổ chức cho hệ thống. Đi đôi với điều này, việc phát triển các ngôn ngữ lập trình cũng đã đáp ứng được phần nào về giải quyết yêu cầu phức tạp của hệ thống. Wenger đã phân loại ra một số ngôn ngữ lập trình bậc cao phổ biến và sắp xếp theo thứ tự tùy thuộc và một số đặc tính của từng loại ngôn ngữ: - Thế hệ ngôn ngữ thứ nhất (1954 -195) FORTRAN I Biểu thức toán học ALGOL 58 Biểu thức toán học Flowmatic Biểu thức toán học IPL V Biểu thức toán học - Thế hệ ngôn ngữ thứ hai (1959 – 1961) FORTRAN II Các thủ tục con, tách riêng rẽ các mô hình phức tạp ALGOL 60 Cấu trúc khối, kiểu dữ liệu COBOL Mô tả dữ liệu Lisp Con trỏ, - Thế hệ ngôn ngữ thứ ba (1962 – 1970) PL/1 FORTRAN + ALGOL + COBOL ALGOL 68 Kế thừa nghiêm ngặt từ ALGOL 60 Pascal Kế thừa đơn giản từ ALGOL 60 Simula Lớp, trừu tượng dữ liệu - Giai đoạn (1970 -1980): Trong giai đoạn này có rất nhiều ngôn ngữ khác nhau đuợc phát minh ra. Tuy nhiên có một số ngôn ngữ sau đã được sử dụng rộng rãi: C Hiệu quả, có thể thực thi đuợc FORTRAN 77 Theo chuẩn ANSI
  6. 6 Pascal Kế thừa đơn giản từ ALGOL 60 Simula Lớp, trừu tượng dữ liệu - Giai đoạn hướng đối tượng (1980 – 1990) Smalltalk Ngôn ngữ hướng đối tượng C++ Phát triển từ C và Simula Ada83 Mạnh hơn Pascal Eiffel Phát triển từ Ada và Simula - Giai đoạn Framework (1990 – ngày nay): Nhiều ngôn ngữ mới đuợc phát triển và yêu cầu cần phải tuân theo một tiêu chuẩn nào đó. Do đó dẫn đến việc lập trình theo các Framework Visual Basic Dễ dàng phát triển các giao diện đồ họa cho các ứng dụng Windows Java Kế thừa từ Oak Python Ngôn ngữ kịch bản hướng đối tượng J2EE Dựa trên các Framework cơ bản của Java .NET Dựa trên các đối tượng Framework cơ bản của Microsoft Visual C# Visual Basic .NET Visual Basic cho Framework của Microsoft .NET Bây giờ chúng ta xem xét cấu trúc của mỗi thế hệ ngôn ngữ lập trình. Trong hình 1-1, chúng ta có thể thấy kiến trúc của các ngôn ngữ lập trình ở thế hệ thứ nhất và đầu thời kì thứ 2. Về kiến trúc, chúng được xây dựng bởi các khối cơ bản và các phần được liên kết với nhau như thế nào. Trong hình này, chúng ta có thể thấy rằng các khối cơ bản để xây dựng lên các ứng dụng là các chương trình con.
  7. 7 Các ứng dụng được viết bởi những ngôn ngữ này thông thường được thiết kế với các chương trình con và dữ liệu toàn cục. Các mũi tên trên hình vẽ nói rằng các chương trình phụ thuộc vào các kiểu dữ liệu khác nhau. Trong suốt quá trình thiết kế dữ liệu của một chương trình con có thể tách biệt với dữ liệu của các chương trình con khác. Một lỗi trong một phần của chương trình có thể ảnh hưởng tới toàn bộ hệ thống bởi vì cấu trúc dữ liệu toàn cục được sử dụng cho tất các các chương trình con. Khi chúng ta cần chỉnh sửa một hệ thống lớn, khó có thể duy trì tính toàn vẹn của thiết kế gốc. Kiến trúc của ngôn ngữ lập trình ở cuối giai đoạn 2 và đầu giai đoạn 3 Giữa năm 1960, cuối cùng thì các chương trình cũng được công nhận là trung gian giữa “vấn đề” và máy tính. “ Chương trình đầu tiên, giờ được gọi là thủ tục.” các chương trình con được đề xuất trong giai đoạn 1950 nhưng nó vẫn chưa được coi như là một abstraction ở thời điểm đó. Subprograms được đánh giá như là một hướng tiếp cận để tách các chức năng của chương trình. Các subprogram có thể phục vụ như là một kĩ thuật tóm tắt có 3 hê quả quan trọng. Thứ nhất, các ngôn ngữ lập trình được hỗ trợ với nhiều các truyền tham số khác nhau. Thứ hai, nền tảng của lập trình cấu trúc là sắp xếp, bố trí rõ ràng thông qua các chương trình con. Thứ ba, phương pháp cấu trúc thể hiện được ưu điểm, cung cấp các định hướng để các nhà thiết kế cố gắng xây dựng một hệ thống phức tạp thông qua các chương trình nhỏ hơn được coi là các khối chương trình cơ bản. Kiến trúc lập trình trong giai đoạn này chỉ ra một vài điều không phù hợp của các ngôn ngữ trước đó.
  8. 8 Kiến trúc ngôn ngữ lập trình ở cuối giai đoạn 2 đầu giai đoạn 3 Kiến trúc của ngôn ngữ lập trình ở cuối giai đoạn thứ 3 Trong giai đoạn này, việc phân tích thiết kế các chương trình mang tính quy mô lớn ngày càng nhiều và đòi hỏi nhiều đội, nhiều nhóm phai tham gia cùng một lúc, do vậy rất cần thiết phải chia chương trình ra thành các phần khác nhau. Do đó, hình thành việc chia các chương trình ra thành các module nhỏ như được hiển thị ở hình dưới đây: Kiến trúc ngôn ngữ lập trình của cuối giai đoạn 3 Kiến trúc của đối tƣợng cơ bản và ngôn ngữ lập trình hƣơng đối tƣợng Trừu tượng hóa dữ liệu là quan trọng để kiểm soát sự phức tạp của dữ liệu. 1.2. Nền tảng của mô hình hướng đối tượng Thiết kế hệ thống theo hướng cấu trúc giúp những nhà lập trình viên xây dựng các hệ thống phức tạp sử dụng thuật toán như là các khối cơ bản. Tương tự, thiết kế hệ thống theo hướng đối tượng giúp người lập trình viên khai thác được những điểm mạnh của đối tượng cơ bản và ngôn ngữ lập trình hướng đối tượng, sử dụng lớp và đối tượng như là các khối xây dựng cơ bản.
  9. 9 Trên thực tế, mô hình đối tượng đã bị chi phối bổi một số tác nhân, không chỉ là ngôn ngữ lập trình hướng đối tượng. Thực vậy, như đã thảo luận ở phần trước, nền tảng mô hình hướng đối tượng, mô hình đối tượng đã chứng mình là một khái niệm thống nhất trong khoa học máy tính, không chỉ thích hợp với ngôn ngữ lập trình mà còn thích hợp với thiết kế giao diện người dùng, cơ sở dữ liệu, và ngay cả với kiến trúc của máy tính. Nguyên nhân của việc được ưa chuộng phổ biến đó là hướng đối tượng giúp chúng ta đối phó với các kế thừa phức tạp trong nhiều loại hệ thống khác nhau. Phân tích và thiết kế hướng đối tượng theo đó đưa ra sự phát triển tiên tiến hơn. Nó không phá vỡ các cấu trúc của chương trình đã được thiết kế trước đó. Tuy nhiên, hầu hết các lập trình viên không được huấn luyện khắt khe kỹ năng phân tích và thiết kế hướng đối tượng. 1.3. Các phần tử của mô hình đối tượng Hầu hết các lập trình viên làm việc trên một ngôn ngữ và sử dụng chỉ một phong cách lập trình. Họ lập trình theo mô hình mẫu của ngôn ngữ mà họ sử dụng. Phong cách lập trình được xem như là một cách tổ chức chương trình dựa trên một số các mô hình của lập trình và ngôn ngữ đã viết ra chương trình một cách rõ ràng. Theo thống kê thì có một số kiểu lập trình sau đây: + Hướng thủ tục Các thuật toán + Hướng đối tượng Các lớp và đối tượng + Hướng Logic Các mục đích + Hướng luật Các luật If then + Hướng ràng buộc Các quan hệ bất biế, không đổi. Không có một kiểu lập trình nào mà tốt nhất đối với tất các các loại ứng dụng. Ví dụ: Lập trình theo hướng thủ tục thì tốt đối với việc thiết kế các chương trình liên quan tới việc tính toán Từ trước tới nay đã và đang tồn tại nhiều phương pháp được áp dụng để phân tích thiết kế một hệ thống thông tin. Một trong những phương pháp đó là hướng thủ tục, được sử dụng trong việc giải quyết các vấn đề của hệ thống hiện tại hoặc cho việc xây dựng một hệ thống mới. Có nhiều phương pháp được sử dụng cho việc thiết kế và phát triển hệ thống thông tin bao gồm: Systems Development Life Cycle (SDLC), Rapid Application Development (RAD), Object-Oriented Analysis and Design. Phương pháp SDLC được sử dụng phổ biến nhất đó là Structured System Analysis and Design. Phương pháp cấu trúc cho phép nhà phân tích chia nhỏ hệ thống phức tạp ra thành các hệ thống nhỏ hơn, rõ ràng hơn, và quản lý cũng dễ dàng hơn. Phương pháp OOAD chủ yếu là phân tích theo hướng đối tượng hơn là hướng thủ tục như là phương pháp SSAD. Một đối tượng là một người, địa điểm hay một sự vật được mô tả hay tồn tại trong hệ thống mà có 3 điều cần quan tâm: - Cái gì để phân biệt, nhận biết nó (Định danh của nó và toàn bộ các thuộc tính).
  10. 10 - Quan hệ với cai gì (Quan hệ của nó với các đối tượng khác). - Nó làm những cái gì (Các phương thức của nó thực hiện với CSDL). Phân tích hướng đối tượng là quá trình phát triển một mô hình hướng đối tượng mà trong mô hình này các đối tượng ban đầu biểu diễn các thực thể và các phương thức liên quan tới vấn đề cần giải quyết. Thiết kế hướng đối tượng là quá trình phát triển một mô hình hướng đối tượng, trong giai đoạn này phải xác định được các yêu cầu. Nói tóm lại trong OOAD chúng ta đề cập tới thuật ngữ đối tượng nhiều hơn là chức năng. Phân tích và thiết kế hệ thống theo hƣớng truyền thống System development life Cycle (SDLC) hoặc Structured Systems Analysis and Design (SSAD) là nền tảng cho mọi hoạt động và nhiệm vụ cần thiết để hoàn thành việc phát triển một hệ thống thông tin. Phương pháp này như đã đề cập ở phần trước được gọi là mô hình thác nước. Các vấn đề cơ bản trong SSAD có thể được tóm tắt như sau: - Điều đầu tiên trong SSAD đó là sự phân tích theo hướng từ trên xuống dưới. Ở đây, hệ thống được coi một tổng thể ban đầu. Chủ yếu việc phân tích ở giai đoạn này để hiểu được những đặc tính của hệ thống, bỏ qua những phần nhỏ và chỉ tiết. Những phần này sẽ được phân tích sau. - Tiếp theo, phạm vi của hệ thống được định nghĩa là nơi hệ thống được triển khai. Nhà phân tích tập trung vào 2 mục đích chính: Hệ thống mới cần phải làm những gì và Hệ thống mới làm nó như thế nào? - Phương pháp này yêu cầu người dùng theo sát từ đầu tới khi dự án hoàn thành. Nhà phân tích sẽ gặp gỡ với người dùng và giải quyết vấn để, xác nhật những vấn đề mà người dùng cần. - Hai vấn đề chính trong việc phát triển hệ thống thông tin đó là các quy trình và dữ liệu được xây dựng độc lập với phương pháp này. Các quy trình được xây dựng bởi các lược đồ luồng dữ liệu, lược đồ này mô phỏng luồng dữ liệu giữa quy trình và dữ liệu lưu trữ và nó được thay đổi như thế nào. Mô hình dữ liệu được định nghĩa bằng việc quan hệ giữa các thực thể (ERD), ERD mô tả dữ liệu (thực thể) và sự phối kết hợp giữa chúng. Phân tích thiết kế hệ thống hƣớng đối tƣợng Phương pháp tiếp cận theo hướng đối tượng để phát triển một hệ thống xem hệ thống như là một tập các đối tượng tương tác với nhau, làm việc cùng nhau để hoàn thành nhiệm vụ. Không có sự tách biệt giữa quy trình và chương trình. Không có sự tách biệt giữa thực thể dữ liệu và tệp tin. Một đối tượng là một vấn đề trong hệ thống máy tính. Phương pháp OOAD có thể chia ra làm 2 lĩnh vực chính:
  11. 11 - Phân tích hướng đối tượng: Điều này liên quan tới phát triển mô hình hướng đối tượng của ứng dụng. Điều này xác định đối tượng biểu diễn các thực thể và quan hệ giữa các đối tượng và phương pháp cần thiết để giải quyết vấn đề. - Thiết kế hướng đối tượng: Điều này liên quan tới phát triển mô hình hướng đối tượng của hệ thống cần thiết để thực hiện các yêu cầu. Các nhà phân tích và lập trình phải nghĩ thuật ngữ đối tượng nhiều hơn là chức năng. Mô hình đối tượng dựa trên các yêu tố cơ bản bao gồm: abstraction, encapsulation, modularity, hierarchy Mục tiêu tập trung ủa mô hình đối tượng là phân tích đối tượng. Một hệ thống hướng đối tượng sẽ có một số đối tượng, mỗi đối tượng này sẽ kết hợp với các đối tượng khác để hoàn thành một nhiệm vụ. Bài tập 1) Trình bày sự phát triển của các mô hình lập trình? 2) Trình bày nền tảng của mô hình đối tượng? 3) Các thành phần của mô hình đối tượng?
  12. 12 CHƢƠNG II: LỚP VÀ ĐỐI TƢỢNG 2.1. Cơ bản về đối tượng Trong khóa học này, nhưng chúng ta đã đề cập từ chương trước, đối với sử dụng OOAD thì người phân tích và lập trình sử dụng thuật ngữ đối tượng rất rất nhiều. Vậy ta tự hỏi, đối tượng là gì? Đối tượng là một trường hợp của một sự việc có kiểu cụ thể. Chúng ta lấy một ví dụ về đối tượng là An, một sinh viên trường Đại học Hàng hải. An là một trường hợp trong tất cả các sinh viên của trường Đại học Hàng hải. Chúng ta cũng có thể nói đối tượng là cái gì đó mà chúng ta muốn lấy thông tin về chúng. Ví dụ, tôi muốn quản lý các khóa học khác nhau tại trường Đại học Hàng hải. Theo đó tôi phải tạo các đối tượng mà có thể lưu trữ thông tin về các khóa học này, để chúng ta có thể theo dõi hay lấy thông tin về các khóa học khác nhau. Như vậy, một đối tượng có thể là tồn tại ở dạng vật chất, như là một sinh viên, một khóa học, hay một quyển sách hoặc tồn tại ở dạng trìu tượng như là cảm xúc Trong UML chúng ta xây dựng đối tượng bằng việc sử dụng một hình chữ nhật với 2 phần. Phần trên chứa tên của đối tượng và tên của lớp mà đối tượng thuộc vào lớp đó. Cú pháp chuẩn là: tên đối tượng: tên lớp. Phần dưới liệt kê các thuộc tính của đối tượng đó. 2.2. Mối quan hệ giữa các đối tượng Toàn bộ hệ thống được xây dựng từ rất nhiều lớp và đối tượng. Hoạt động của hệ thống thu được thông qua sự phối hợp của các đối tượng trong hệ thống. Các mối quan hệ cung cấp các đường dẫn để các đối tượng tương tác với nhau. Có hai loại quan hệ giữa các đối tượng là : - liên kết(link) - kết tập (aggregation) Mối quan hệ liên kết (link)
  13. 13 Mối quan hệ liên kết là sự kết nối vật lý hoặc logic giữa các đối tượng. Một đối tượng phối hợp với các đối tượng khác thông qua các liên kết của nó với các đối tượng này. Nói một cách khác, một liên kết biểu diễn một liên hợp (association) xác định, trong đó một đối tượng(client) sử dụng những dịch vụ của đối tượng khác (supplier). Thông thường, thông điệp được truyền giữa hai đối tượng là một chiều, đôi khi có thể là cả hai chiều. Các thông điệp được khởi tạo ở phía client, sau đó được đưa tới supplier, còn dữ liệu có thể dịch chuyển theo cả hai chiều trên liên kết. Với mỗi liên kết, một đối tượng có thể có một trong ba vai trò: Actor: Một đối tượng có thể hoạt động trên các đối tượng khác chứ không bị thao tác bởi các đối tượng khác. Server: Một đối tượng không bao giờ hoạt động trên các đối tượng khác; nó chỉ có thể bị thao tác bởi các đối tượng khác. Agent: Là đối tượng vừa có thể hoạt động trên các đối tượng khác, lại vừa có thể bị các đối tượng khác thao tác. Mối quan hệ kết tập (aggregation) Mối quan hệ kết tập chỉ là một dạng đặc biệt của mối quan hệ liên hợp trong đó một đối tượng là sự tổng hợp của các đối tượng thành phần. Ví dụ: Một chiếc xe ô tô có 4 bánh, một cần lái, một hộp số, một động cơ 2.3. Cơ bản về lớp Lớp là một sự trìu tượng trong mô hình hướng đối tượng và trong ngôn ngữ hướng đối tương. Một lớp bao gồm cấu trúc và hành vi. Các lớp có thể định nghĩa thông qua các lớp khác bằng việc sử dụng tính chất kế thừa. Một lớp là mô tả cho một tập đối tượng có thuộc tính và hoạt động giống nhau. Nó phục vụ như là một mẫu khi mà tạo một đối tượng mới. Mục đích của nó là định nghĩa một tập các thuộc tính và thao tác mà mô tả đầy đủ cấu trúc và hành vi của các đối tượng. Trong cách nói khác thì đối tượng là một trường hợp cụ thể của lớp. Nó luôn luôn bắt nguồn từ lớp. Nó có cấu trúc và hành vi tùy theo sự mô tả trong lớp. Trong UML một lớp được biểu diễn như là một hình chữ nhật với 3 phần riêng biệt được phân tách bởi dòng kẻ ngang. Phần trên cùng thể hiên tên lớp, phần giữa định nghĩa tất cả các thuộc tính của lớp, phần cuối cùng chứa các định nghĩa thao tác.
  14. 14 Lớp là một loại đối tượng đặc biệt. Nó là một tập hợp các đối tượng đã được tạo. Nó được dùng để tạo và huỷ các đối tượng thuộc về nó. Nó cũng có thể được dùng để lưu dữ liệu và cung cấp cho các dịnh vụ trong cùng nhóm. Một ứng dụng có thể truy cập các dịch vụ của nó thông qua tên lớp. 2.2.1. Các phƣơng pháp đƣợc sử dụng để xác định lớp Trong thực tế có rất nhiều phương pháp có thể xác định được lớp trong một hệ thống. Tuy nhiên ở đây tôi đề cập tới 2 phương pháp hay được dùng nhất: - Xác định các danh từ. - Xác định lớp dựa trên khái niệm về danh sách lớp.
  15. 15 2.4. Mối quan hệ giữa các lớp Quan hệ giữa các lớp có 4 loại: Liên hệ ( Association) Khái quát hoá (Generalization) Phụ thuộc (Dependency) Nâng cấp (Refinement) Một liên hệ là một số nối kết giữa các lớp, cũng có nghĩa là sự nối kết giữa các đối tượng của các lớp này. Trong UML, 1 liên hệ được định nghĩa là một mối quan hệ mô tả một tập hợp các nối kết trong khi nối kết được định nghĩa là một sự liên quan về ngữ nghĩa giữa một nhóm các đối tượng. Khái quát hoá là mối quan hệ giữa một yếu tố mang tính khái quát cao hơn và một yếu tố chuyên biệt hơn. Có thể chứa chỉ các thông tin bổ sung một thực thể (một đối tượng là một thực thể của một lớp) của yếu tố mang tính chuyên biệt hơn có thể được sử dụng ở bất cứ nơi nào mà đối tượng mang tính khái quát hoá hơn được phép. Sự phụ thuộc là một quan hệ giữa các yếu tố gồm một yếu tố mang tính độc lập và một yếu tố mang tính phụ thuộc một sự thay đổi trong yếu tố độc lập sẽ ảnh hưởng đến yếu tố phụ thuộc. Một sự nâng cấp là một quan hệ giữa hai lời mô tả của cùng một sự vật, nhưng ở những mức độ trừu tượng hoá khác nhau. 2.5. Sự tương tác lẫn nhau của lớp và đối tượng Lớp vàđối tượng, mặc dù có mối liên hệ tươngứng lẫn nhau, nhưng bản chất lại khác nhau: Lớp là sự trừu tượng hoá của các đối tượng. Trong khi đó, đối tượng là một thể hiện của lớp. Đối tượng là một thực thể cụ thể, có thực, tồn tại trong hệ thống. Trong khi đó, lớp là một khái niệm trừu tượng, chỉ tồn tại ở dạng khái niệmđể mô tả cácđặc tính chung của một số đối tượng. Tất cả các đối tượng thuộc về cùng một lớp có cùng các thuộc tính và các phương thức. Một lớp là một nguyên mẫu của một đối tượng. Nó xác định các hành động khả thi và các thuộc tính cần thiết cho một nhóm các đối tượng cụ thể. Nói chung, lớp là khái niệm tồn tại khi phát triển hệ thống, mang tính khái niệm, trừu tượng. Trong khi đó, đối tượng là một thực thể cụ thể tồn tại khi hệ thống đang hoạt động. Bài tập 1) Đối tượng là gì? Mối quan hệ giữa các đối tượng? 2) Lớp là gì? Mối quan hệ giữa các lớp? 3) Trình bày mối quan hệ giữa Lớp và Đối tượng?
  16. 16 CHƢƠNG III: SỰ PHÂN LOẠI Sự phân loại được thực hiện dựa trên những gì hiểu biết của chúng ta. Trong thiết kế hướng đối tượng, việc phân loại các đối tượng cùng với các tương tác của nó trong hệ thống là vô cùng quan trọng. Nếu như chúng ta phân loại không đúng thì hệ thống chúng ta sẽ cồng kềnh, hoạt động không hiệu quả, khó khăn trong việc triển khai và lập trình. Tuy nhiên nếu chúng ta có cái nhìn tốt và việc phân loại các đối tượng, xây dựng các lớp chính xác sẽ dẫn tới hệ thống chúng ta thiết kế rõ ràng, và triển khai cũng dễ hơn, nhanh hơn, tránh được việc trùng lặp công việc. Không có một quy định chung nào để tìm ra được sự phân loại tốt nhất, tất cả đều phải dựa trên kinh nghiệm và yêu cầu của hệ thống hiện tại. 3.1. Tầm quan trọng của việc phân loại hợp lý Việc xác định các lớp và các đối tượng là một trong những phần đầy thử thách của phân tích và thiết kế hướng đối tượng. Kinh nghiệm cho thấy rằng xác định bao gồm cả phát hiện và sáng tạo. Thông qua phát hiện, chúng ta có thể nhận ra được những lớp trìu tượng và kĩ thuật mà tạo nên vấn đề. Thông qua sáng tạo, chúng ta đưa ra những khái quát trìu tượng cũng như các kĩ thuật mới xác định các đối tượng cộng tác như thế nào. Cuối cùng, phát hiện và sáng tạo là các vấn đề trong phân loại và việc phân loại là đi tìm những vấn đề tương tự nhau. Khi chúng ta phân loại, chúng ta tìm đến những nhóm sự việc mà có chung một cấu trúc hoặc các hành vi chung, phổ biến. Phân loại giúp chúng ta cách xác định những lớp tổng quát, và sự phân cấp giữa các lớp với nhau. Bằng việc nhận ra các tương tác chung giữa các đối tượng, chúng ta đưa ra các kĩ thuật được coi là quyết định trong việc thực hiện. Việc phân loại cũng hướng dẫn chúng ta trong việc đưa ra những quyết định về module hóa. Chúng ta có thể chọn và đặt toàn bộ các lớp và đối tượng trong cùng một module hoặc trong các module khác nhau, tùy thuộc vào sự giống nhau mà chúng ta tìm thấy giữa các lớp và đối tượng đó. Phân loại cũng đóng vai trò trong việc chỉ định các quy trình xử lý. Chúng ta có thể đặt toàn bộ các quy trình cùng với nhau trong một bộ xử lý hoặc ở các bộ xử lý khác nhau, tùy thuộc vào việc đóng gói, chức năng hoặc là độ tin cậy. 3.2. Xác định các lớp và đối tượng Vấn đề phân loại đã được vô số các nhà triết học, ngôn ngữ học, các nhà khoa học và cả các nhà toán học đặc biệt quan tâm. Chúng ta có thể tham khảo những kinh nghiệm của họ ở trong lĩnh vực phân loại này vào việc thiết kế hướng đối tượng nhờ sự phân loại. Phƣơng pháp tiếp cận cổ điển và hiện đại Có 3 hướng tiếp cận phổ biến thường được dùng để phân loại:
  17. 17 - Loại cổ điển. - Nhóm khái niệm. - Lý thuyết nguyên mẫu Loại cổ điển Trong hướng tiếp cận cổ điển để phân loại, ”Tất cả các thực thể mà có một thuộc tính hoặc một tập các thuộc tính giống nhau tạo lên một loại. Như là các thuộc tính cần thiết và đủ để định nghĩa một loại”. Nhóm khái niệm. Với hướng tiếp cận này thì các lớp được tạo ra do việc xây dựng các khái niệm mô tả đầu tiên của lớp này và sau đó phân loại các thực thể theo các mô tả. Lý thuyết mẫu Một lớp của các đối tượng được miêu tả bởi một đối tượng nguyên mẫu, và một đối tượng được coi như là một thành viên của lớp đó nếu và chỉ nếu nó nó tương tự với các mẫu này. Bài tập 1) Sự phân loại là gì? Tầm quan trọng của sự phân loại? 2) Trình bày phương pháp xác định lớp và đối tượng?
  18. 18 CHƢƠNG IV: PHÂN TÍCH VÀ THIẾT KẾ HƢỚNG ĐỐI TƢỢNG SỬ DỤNG UML 4.1. Ngôn ngữ mô hình thống nhất UML UML là ngôn ngữ chuẩn cho việc quy định các tiêu chuẩn, hình dung, xây dựng, và tài liệu của một hệ thống phần mềm. UML là viết tắt của Unified Modeling Language. UML hoàn toàn khác với các ngôn ngữ lập trình hướng đối tượng như C++, java UML được sử dụng cho việc tạo các bản kế hoạch cho việc phát triển phần mềm. UML không phải là ngôn ngữ lập trình, nhưng các công cụ có thể được dùng để sinh ra mã lệnh trong các ngôn ngữ khác nhau. UML có mối liên quan mật thiết với phân tích và thiết kế hệ thống hướng đối tượng. Vì vậy trong bài giảng này tôi sử dụng UML như là một công cụ chính trong việc thiết kế và giảng dạy. 4.1.1 Các khối cơ bản trong UML UML đóng vai trò quan trọng trong việc tạo nên mô hình khái niệm. Mô hình khái niệm của UML có thể được tạo bởi 3 phần từ chính sau: - Các khối UML - Các luật, nguyên tắc để kết nối giữa các khối - Kỹ thuật chung của UML. Các khối của UML có thể được định nghĩa là: - Things. - Relationships. - Diagrams. 4.1.2. Things Things là các khối quan trọng của UML. Things có thể là: Structural, Behavioral, Grouping và Annotational. Structural things: Structural things định nghĩa phần cố định của mô hình. Chúng thể hiện các phần từ vật lý và khái niệm. Có một số Strutural things sau: - Class: biểu diễn cho một tập các đối tuwngj có cùng trách nhiệm, nhiệm vụ. Phần trên cùng biễu diễn tên lớp. Phần thứ 2 biểu diễn các thuộc tính của lớp. Phần thứ 3 được dùng để mô tả các thao tác có thể được thực hiện. Phần thứ 4 là phần lựa chọn dùng để hiển thị thêm các thành phần phụ thêm
  19. 19 - Interface: định nghĩa một tập các thao tác mà đặc tả rõ trách nhiệm của hệ thống. Được biểu diễn bằng một hình tròn, bên dưới ghi tên của giao diện. Được dùng để mô tả các chức năng, mô tả cái chung nhất. Trong giao diện chưa có viết mã lệnh để thực thi. - Collaboration: định nghĩa sự tương tác lẫn nhau giữa các phần tử. Collaboration được biểu diễn bằng hình eclips nét đứt. Tên của nó được ghi ở bên trong hình. - Use case: biểu diễn một tập các hoạt động được thực hiện bởi một hệ thống cho một mục đích xác định. Use case được biểu diễn bằng hình eclip liền nét với tên được ghi bên trong hình.
  20. 20 - Actor có thể được định nghĩa như là các thực thể bên trong hoặc bên ngoài tương tác với hệ thống. - Kí hiệu bắt đầu: được dùng để khởi tạo, bắt đầu một quy trình xử lý. - Kí hiệu kết thúc: Được dùng để báo hiệu kết thúc một quá trình xử lý. - Active class: có cấu tạo giống với class nhưng đường viền bên ngoài đậm hơn. Được dùng để miêu tả hành động hiện hành của hệ thống. - Component: Mô tả phần vật lý của hệ thống. Tên của nó được ghi ở bên trong hình và có thể add thêm các phần tử khác nếu cần thiết.
  21. 21 - Node: mô tả phần tử vật lý mà tồn tại trong thời gian chạy chương trình. Node được biểu diễn bởi hình vuông với tên được ghi ở trong hình. Behavioral things: Behavioral thing gồm có các phần động của mô hình UML. Theo đó có một số loại behavioral things sau: - Interaction: được định nghĩa như là một hoạt động bao gồm một nhóm các thông điệp được chuyển giữa các phần tử để hoàn thành một nhiệm vụ rõ ràng, riêng biệt. - State machine: State machine định nghĩa một chuỗi các trạng thái mà một đối tượng phải trải qua trong việc đáp ứng sự kiện. Các sự kiện là những tác nhân bên ngoài chịu trách nhiệm thay đổi. Grouping things: có thể được định nghĩa như là một kĩ thuật để nhóm các phần tử của mô hình UML lại với nhau. Chỉ có duy nhất một loại Grouping thing: Package. Annotation things: có thể được định nghĩa như là một kĩ thuật để đánh dấu, chú thích, mô tả của cuác phần tử UML. Note là Annotational thing duy nhất. 4.1.3. Quan hệ Quan hệ giữa các phần tử cũng là một khối quan trọng của UML. Nó cho thấy các phần tử được liên kết với nhau như thế nào và sự kết hợp này mô tả chức năng của chương trình. Có 4 loại quan hệ được đề cập sau đây: - Dependency: là loại quan hệ giữa 2 sự việc mà khi có một phần tử thay đổi thì cũng ảnh hưởng tới một phần tử khác.
  22. 22 - Association là liên kết cơ bản được dùng để kết nối giữa các phần tử trong mô hình UML. Nó cũng mô tả các đối tượng liên kết với nhau như thế nào. - Generalization: có thể được định nghĩa như là một quan hệ mà kết nối một phần tử chuyên dụng với những phần tử chung. Nó mô tả quan hệ kế thừa của các đối tượng. - Realization: có thể được định nghĩa như là một quan hệ trong đó 2 phần tử được liên kết với nhau. Một phần tử mô tả một số trách nhiệm mà chưa được thực thi và môt phần tử khác thì thực thi chúng. Kiểu quan hệ này tồn tại trong trường hợp interface. 4.1.4. UML Diagram Tất cả các phần tử, quan hệ giữa chúng tạo nên một biểu đồ UML hoàn chỉnh và lược đồ này biểu diễn một hệ thống. Biểu đồ UML là 1 phần quan trong trong toàn bộ quy trình. UML bao gồm 9 lược đồ sau: - Class diagram. - Object diagram. - Use case diagram. - Sequence diagram. - Collaboration diagram. - Activity diagram. - Statechart diagram. - Deployment diagram. - Component diagram. 4.1.5. Kiến trúc UML Bất kỳ hệ thống nào cũng được sử dụng bởi những người dùng khác nhau. Người dùng có thể là lập trình viên, phát triển, kiểm thử, nhà đầu tư, nhà phân tích Vì vậy trước khi thiết kế một hệ thống được hình thành với các phối cảnh khác nhau trong suy nghĩ của từng người dùng. UML đóng vai trò quan trọng trong việc mô tả các cách nhìn nhận khác nhau của hệ thống. Có một số cách nhìn nhận sau đây:
  23. 23 - Design của một hệ thống bao gồm các lớp, giao diện và các cộng tác. UML cung cấp biểu đồ lớp, biểu đồ đối tướng để hỗ trợ cách thiết kế này. - Implementation định nghĩa các thành phần được sắp xếp lại với nhau để tạo nên một hệ thống vật lý hoàn chỉnh. Biểu đồ thành phần UML được dùng để hỗ trợ thực thi theo cách này. - Process định nghĩa luồng của hệ thống. Sử dụng các phần tử giống như ở trong Design. - Deployment biểu diễn các nút vật lý của hệ thống mà tạo nên phần cứng. Lược đồ triển khai được sử dụng để hỗ trợ khía cạnh này. 4.2. Các biểu đồ 4.2.1. Class diagram Giới thiệu Biểu đồ lớp là một dạng biểu đồ tĩnh. Nó biểu diễn cái nhìn tĩnh của một ứng dụng. Biểu đồ lớp không chỉ được dùng cho việc mô tả bên ngoài, lập tài liệu của các ảnh hưởng khác nhau của hệ thống mà còn xây dựng nên mã lệnh cho ứng dụng. Trong biểu đồ lớp miêu tả các thuộc tính và các thao tác của một lớp và cũng giàng buộc với hệ thống. Biểu đồ lớp được sử dụng rộng rãi trong việc thiết kế mô hình hướng đối tượng bởi vì chỉ có biểu đồ UML mới có thể ánh xạ trực tiếp sang ngôn ngữ hướng đối tuợng. Biểu đồ lớp biểu diễn một tập các lớp, giao diện, kết hợp, cộng tác, và giằng buộc. Biểu đồ lớp được xem như là biểu đồ cấu trúc. Mục đích Mục đích của biểu lớp là xây dựng lên cách nhìn tĩnh của ứng dụng. Biểu đồ lớp là biểu đồ mà có thể ánh xạ trực tiếp sang ngôn ngữ lập trình hướng đối tượng. Mục đích của biểu đồ lớp có thể tóm tắt như sau: - Phân tích và thiết kế cách nhìn tĩnh của ứng dụng. - Mô tả các trách nhiệm, chức năng của hệ thống. - Làm nền tảng cho biểu đồ thành phần và biểu đồ triển khai. Vẽ biểu đồ lớp nhƣ thế nào? Biểu đồ lớp có nhiều thuộc tính cần phải chú ý trong khi vẽ nhưng ở đây, trong tài liệu này chỉ đề cập tới những thuộc tính cơ bản nhất và hay dùng nhất. Một số điểm cần chú ý khi vẽ biểu đồ lớp: - Tên của biểu đồ lớp nên đặt sao cho có thể mô tả được diện mạo của hệ thống. - Mỗi một phần tử và các quan hệ của nó phải rõ ràng. - Khả năng của lớp (thuộc tính và thao tác) phải rõ ràng và duy nhất.
  24. 24 - Chỉ biểu diễn những thuộc tính đặc biệt của lớp, bởi vì những nếu chúng ta biểu diễn cả những thuộc tính không quan trọng sẽ làm cho hệ thống phức tạp, rối và khó triển khai. - Sử dụng note khi được yêu cầu mô tả diện mạo của biểu đồ. Bởi vì mục đích cuối cùng là làm cho người dùng và lập trình viên có thể hiểu được hệ thống được mô tả như thế nào. Ví dụ: Vẽ biểu đồ lớp của một hệ thống đơn đặt hàng trong một ứng dụng bán hàng. Hệ thống này được mô tả như sau: - Đầu tiêu tất cả các Order (đơn đặt hàng) và Customer (Khách hàng) được xác định như là 2 phần tử của hệ thống và chúng có quan hệ 1-n bởi vì khách hàng có thể có nhiều Order (Đơn đặt hàng). - Chúng ta hãy tưởng tượng lớp Order là một lớp trìu tượng và nó có 2 lớp thực tế tồn tại (Kế thừa từ lớp Order) đó là SpecialOrder và NormalOrder. - Hai lớp kế thừa có tất cả các thuộc tính của lớp Order. Thêm vào đó chúng có thêm các chức năng như là dispatch() và receive(). 4.2.2. Sơ đồ Object Sơ đồ Object thu được từ sơ đồ lớp vì vậy sơ đồ đối tượng có được là dựa trên sơ đồ lớp. Các sơ đồ đối tượng biểu diễn một trường hợp của một sơ đồ lớp. Về cơ bản sơ đồ lớp và sơ đồ đối tượng là tương tự nhau. Sơ đồ đối tượng cũng biểu diễn cách nhìn tĩnh của một hệ thống nhưng hướng nhìn tĩnh này là snapshot của hệ thống tại các thời điểm khác nhau. Sơ đồ đối tượng được dùng để đưa ra một tập các đối tượng và quan hệ giữa chúng.
  25. 25 Mục đích Mục đích của việc sử dụng sơ đồ là làm cho chúng ta có thể hiểu được rõ ràng để triển khai hệ thống một cách hiệu quả. Mục đích của sơ đồ đối tượng cũng giống như mục đích của sơ đồ lớp. Sự khác nhau giữa 2 sơ đồ đó là sơ đồ lớp biểu diễn một mô hình trìu tượng bao gồm các lớp và quan hệ giữa chúng. Nhưng sơ đồ đối tượng biểu diễn một trường hợp tại một thời điểm cụ thể. Có nghĩa là sơ đồ đối tượng miêu tả sát với hệ thống thực hơn. Mục đích là lấy được hướng nhìn tĩnh của hệ thống tại một thời điểm riêng biệt. - Chuyển tới và nhận lại từ các kĩ sư phần mềm - Biểu diễn quan hệ giữa các đối tượng của một hệ thống. - Hướng nhìn tĩnh một tương tác. - Hiểu các hoạt động của đối tượng và quan hệ giữa chúng. Vẽ sơ đồ đối tƣợng nhƣ thế nào? Như chúng ta đã đề cập ở phần trước, một sơ đồ lớp là một trường hợp của sơ đồ lớp. Điều đó ngụ ý nói rằng, một sơ đồ đối tượng bao gồm các trường hợp của sự việc được sử dụng trong sơ đồ lớp. Cả hai sơ đồ đề được tạo từ các thành phần cơ bản nhưng cách thành lập khác nhau. Trong sơ đồ lớp các phần tử là ở dạng trìu tượng miêu tả bản kế hoạch hoặc sơ đồ và trong sơ đồ đối tượng các phần tử là tồn tại hiện hữu biểu diễn đối tượng trong thế giới thực. Để lấy được các hệ thống riêng biệt, số sơ đồ lớp được giới hạn. Nhưng nế chung ta theo dõi sơ đồ đối tượng thì chúng ta có thể không giới hạn các trường hợp của sơ đồ này. Từ những gì đưa ra ở trên thì một sơ đồ đối tượng đơn không thể lấy được tất cả các trường hợp hay không thể mô tả được hết tất cả các đối tượng của hệ thống. Vì thế giải pháp để giải quyết vấn đề này là: - Đầu tiên, phân tích hệ thống và quyết định trường hợp nào có dữ liệu và mối liên kết quan trọng. - Tiếp theo, theo dõi các trường hợp này cùng với tất cả các chức năng có thể. - Lựa chọn một số trường hợp tốt nhất. Trước khi vẽ sơ đồ đối tượng chúng ta nên nhớ một số điều sau đây: - Sơ đồ đối tượng chứa các đối tượng. - Liên kết trong sơ đồ đối tượng được dùng để kết nối các đối tượng. - Các đối tượng và các liên kết là 2 phần tử dùng để xây dựng lên một sơ đồ đối tượng. Ví dụ: Chúng ta sử dụng ví dụ ở phần Sơ đồ lớp “Order management System” (Hệ thống quản lý đơn đặt hàng). Khi có khách hàng tới đặt mua hàng, tại thời điểm đó sẽ có những đối tượng sau: - Customer (Khách hàng).
  26. 26 - Order (Đơn đặt hàng). - SpecialOrder. - NormalOrder. Bây giờ đối tượng khách hàng (C) được liên kết với 3 đối tượng đơn đặt hàng (O1, O2, và O3). Những đối tượng đơn đặt hàng này được liên kết với đơn đặt hàng đặc biệt hoặc là bình thường (S1, S2 và N1). Khách hàng có 3 đơn đặt hàng với các số lượng khác nhau (12, 32 và 40) cho từng thời điểm theo dõi. Khách hàng có thể tăng số lượng đơn đặt hàng lên trong thời gian tới và trong trường hợp đó số lượng sơ đồ đối tượng sẽ phản ánh rằng: nếu đơn đặt hàng, đối tượng đơn đặt hàng đặc biệt hoặc là bình thường được theo dõi thì chúng ta sẽ tìm thấy chúng có một vài giá trị. Với các đơn đặt hàng có giá trị là 12, 32 và 40 cho thấy rằng các đối tượng có giá trị tại thời điểm được quan sát. 4.2.3. Sơ đồ thành phần Các sơ đồ thành phần được dùng để xây dựng lên diện mạo vật lý của hệ thống. Vậy chúng ta tự hỏi diện mạo vật lý của hệ thống là gì? Diện mạo vật lý của hệ thống là các thành phần giống như các tệp tin, các thư viện, các tài liệu, các tệp tin có thể thực thi tồn tại ở bên trong node. Vì vậy, các sơ đồ thành phần được dùng để mô tả mường tượng về cách tổ chức và mối quan hệ giữa các thành phần trong hệ thống. Những sơ đồ này cũng được dùng để tạo các hệ thống có thể thực thi. Mục đích Sơ đồ thành phần là một loại sơ đồ đặc biệt trong UML. Mục đích của nó cũng khác với các sơ đồ khác. Nó không miêu tả các chức năng của hệ thống nhưng nó miêu tả các thành phần được dùng để tạo nên các chức năng đó. Sơ đồ thành phần có thể được miêu tả như là sự thi hành tĩnh của hệ thống. Sự thi hành tĩnh biểu diễn cách tổ chức các thành phần tại các thời điểm riêng biêt. Một sơ đồ thành phần đơn không thể biểu diễn được toan bộ hệ thống nhưng một tập hợp các sơ đồ được dùng biểu diễn toàn bộ hệ thống. Vì thế những mục đích của sơ đồ thành phần có thể được tóm tắt như sau:
  27. 27 - Hình dung các thành phần của hệ thống. - Xây dựng khả năng có thể thực thi bằng việc chuyển tới và nhận lại từ các kĩ sư phần mềm. - Mô tả cách tổ chức và quan hệ giữa các thành phần. Vẽ sơ đồ thành phần nhƣ thế nào? Sơ đồ thành phần được dùng để mô tả các phần vật lý của hệ thống. Các phần này có thể là tệp tin, file thực thi, thư viện Vì thế mục đích của sơ đồ này có khác, Sơ đồ thành phần được sử dụng trong suốt giai đoạn thi hành của ứng dụng. Ban đầu, hệ thống được thiết kế bằng việc sử dụng các sơ đồ UML khác và sau đó khi các dụng cụ là các sơ đồ thành phần được sử để lấy một ý tưởng của việc thi hành. Sơ đồ này rất quan trọng bởi vì nếu không có nó không một ứng dụng nào có thi hành một cách hiệu quả. Vì vậy trước khi vẽ sơ đồ thành phần các dụng cụ sau phải được xác định rõ ràng: - Các tập tin được dùng trong hệ thống. - Các thư viện và các dụng cụ khác liên quan tới ứng dụng. - Quan hệ giữa các vật dụng. Sau khi xác định các dụng cụ, vật dụng, một số điểm sau cần được lưu ý: - Sử dụng một tên đầy đủ nghĩa để xác định thành phần cho mỗi sơ đồ được vẽ - Chuẩn bị các tài liệu trước khi sử dụng công cụ. - Sử dụng node để ghi chú những điểm quan trọng. Dưới đây là sơ đồ thành phần cho hệ thống quản lý đơn đặt hàng của ví dụ ở phần trước. ở đây dụng cụ là các tệp tin. Vì thế sơ đồ biểu diễn các tệp tin trong ứng dung và mối quan hệ giữa chúng. Trong thực tế sơ đồ thành phần chứa dlls, các thư viện, các thư mục Trong sơ đồ thành phần dưới đây 4 tệp tin được xác đinh và quan hệ giữa chúng được tạo ra. Sơ đồ thành phần không giống như các sơ đồ UML khác bởi vì nó có mục đích khác các sơ đồ trước.
  28. 28 4.2.4. Sơ đồ triển khai Sơ đồ triển khai được dùng để hình dung cấu trúc của các thành phần vật lý của hệ thống nơi mà các thành phần phần mềm được triển khai. Vì vậy, các sơ đồ triển khai được sử dụng miêu tả hướng nhìn triển khai tĩnh của hệ thống. Sơ đồ triển khai bao gồm các node và các mối quan hệ giữa chúng. Mục đích Từ triển khai bản thân nó cũng mô tả được mục đích của sơ đồ. Sơ đồ triển khai được dùng để mô tả các thành phần phần cứng nơi mà phần mềm được triển khai. Sơ đồ thành phần và sơ đồ triển khai có quan hệ chặt chẽ với nhau. Sơ đồ thành phần được dùng để miêu tả các thành phần và sơ đồ triển khai để miêu tả các thành phần được triển khai như thế nào trong phần cứng. UML được sử dụng để thiết kế tập trung và các “dụng cụ” phần mềm của hệ thống. Nhưng 2 sơ đồ đó là 2 sơ đồ đặc biệt được tạo ra đề tập trung vào cấu trúc phần cứng của hệ thống. Sơ đồ triển khai được sử dụng bởi các kĩ sư hệ thống. Có thể tóm tắt các mục đích của sơ đồ triển khai như sau: - Hình dung cấu trúc phần cứng của hệ thống. - Mô tả các thành phần phần cứng của hệ thống được dùng để triển khai các thành phần phần mềm. - Miêu tả quá trình thực thi. Vẽ sơ đồ triển khai nhƣ thế nào?
  29. 29 Sơ đồ triển khai biểu diễn hướng nhìn triển khai của hệ thống. Nó liên quan tới sơ đồ thành phần. Bởi vì các thành phần được triển khai sử dụng sơ đồ triển khai. Một sơ đồ triển khai bao gồm các nút. Các nút là nothing nhưng là các phần cứng vật lý được dùng để triển khai ứng dụng. Các sơ đồ triển khai rất hữu ích cho các kĩ sư hệ thống. Một sơ đồ triển khai tốt là rất quan trọng nó ảnh hưởng tới chất lượng của ứng dụng. Nó ảnh hướng tới các chức năng sau: - Việc thực thi. - Khả năng mở rộng - Khả năng bảo trì - Portable Khi vẽ một sơ đồ triển khai chúng ta nên xác định - Các nút - Quan hệ giữa các nút Dưới đây là một ví dụ về sơ đồ triển khai của hệ thống quản lý đơn đặt hàng. Chúng ta xác định các nút sau: - Màn hình. - Modem - Caching Server - Server Giả sử ứng dụng được triển khai dưới dạng WEB và chia ra các làm 3 cụm server: server 1, server 2, server 3. Người dùng sẽ kết nối tới ứng dụng qua đường truyền internet. Việc điều khiển sẽ được điều khiển từ caching server tới các cụm.
  30. 30 4.2.5. Sơ đồ Use Case Để xây dựng một hệ thống, điều quan trọng là phải xử lý và theo dõi được những hành vi động. Hành vi động nghĩa là những hành vi của hệ thống khi chương trình chạy hoặc hoạt động. Vì vậy chỉ có hành vi tĩnh thì không đủ để xây dựng lên một hệ thống mà chúng ta cần phải có cả nhưng hành vi động. Trong UML có 5 sơ đồ để xây dựng hành vi động của hệ thống và sơ đồ use case là một trong số đó. Có những tác nhân bên trong và bên ngoài hệ thống được biết như là những actors. Vì thế sơ đồ use case bao gồm các actors, use case và các mối quan hệ giữa chúng. Sơ đồ này được sử dụng để xây dựng lên hệ thống hoặc các hệ thống con của ứng dụng. Một sơ đồ use case biểu thị một chức năng riêng biệt của hệ thống. Vì thế để xây dựng toàn bộ hệ thống thì chúng ta cần phải xây dựng nhiều hơn một sơ đồ use case. Mục đích Mục đích của sơ đồ Use case là để nắm bắt các khía cạnh động của hệ thống. Nó được dùng để thu thập những yêu cầu của hệ thống bao gồm những tác nhân bên trong hoặc bên ngoài. Những yêu cầu này phần lớn là yêu cầu thiết kế. Vì vậy khi phân tích hệ thống để thu thập những chức năng có thể các use case được chuẩn bị và các tác nhân (actors) được xác định. Có thể tóm tắt các mục đích của việc sử dụng sơ đồ use case như sau: - Được dùng để thu thập các yêu cầu của hệ thống. - Được sử dụng để có cái nhìn khách quan từ bên ngoài của hệ thống. - Xác định các yếu tố bên trong và bên ngoài ảnh hưởng tới hệ thống. - Chỉ ra tương tác giữa các yêu cầu và các tác nhân. Vẽ sơ đồ Use case nhƣ thế nào? Sơ đồ use case được xem như là phân tích yêu cầu mức cao của hệ thống. vì vậy, khi yêu cầu của hệ thống được phân tích các chức năng được thu thập lại trong use case. Trong sơ đồ tác nhân, các tác nhân có thể là người dùng, các ứng dụng bên trong khác, hoặc các ứng dụng bên ngoài. Vì vậy khi vẽ sơ đồ use case ta cần xác định một số phần tử sau. - Chức năng được biểu diễn như một use case. - Các tác nhân. - Quan hệ giữa các use case và tác nhân. Khi vẽ sơ đồ use case chúng ta cần chú ý một số điểm sau: - Tên của use case rất quan trọng. Chọn tên sao cho có thể xác định được chức năng được thực hiện. - Đặt tên cho các tác nhân một cách dễ nhớ. - Chỉ ra các mối quan hệ và độc lập trong sơ đồ. - Sử dụng note khi yêu cầu làm rõ một vấn đề quan trọng nào đó.
  31. 31 Tiếp theo ví dụ trên, ta vẽ sơ đồ use case để thể hiện hệ thống quản lý đơn đặt hàng. Trong ví này ta xác định được 3 use cases (Order, SpecialOrder, NormalOrder) và một tác nhân đó là Customer. SpecialOrder và NormalOrder use cases được suy ra từ Order use cases. Vi vậy chúng có quan hệ mở rộng với nhau. Một điểm quan trọng khác là để xác định ranh giới của hệ thống. Tác nhân customer nằm ngoài hệ thống được xem như là người dùng ngoài hệ thống. 4.2.6. Sơ đồ tƣơng tác Ngay từ cái tên là sơ đồ tương tác chung ta cũng có thể hiểu được sơ đồ này được dùng để miêu rả các kiểu tương tác giữa các thành phần khác nhau trong mô hình. Vì vậy tương tác là một phần của hành vi động của hệ thống. Hành vi tương tác được biểu diễn trong UML bằng 2 sơ đồ được biết như là Sequence diagram và Collaboration diagram. Sequence diagram nhấn mạnh về các chuỗi thông báo và collaboration diagram nhấn mạnh về cấu trúc tổ chức của các đối tượng mà gửi và nhận thông báo. Mục đích Mục đích của biểu đồ tương tác là hình dung hành vi tương tác của hệ thống. Hình dung các hành vi tương tác là công việc khó. Vì vậy giải pháp là sử dụng các mô hình khác nhau để nắm bắt được các diện mạo khác nhau của quá trình tương tác. Đó là vì tại sao sequence và collaboration diagram được sử dụng để nắm bắt bản chất động nhưng khác với di chuyển. Vì vậy mục đích của việc dùng sơ đồ tương tác có thể được miêu tả ngắn gọn như sau: - Để nắm bắt các hành vi động của hệ thống. - Để mô tả luồng thông báo trong hệ thống. - Để mô tả cấu trúc tổ chức của các đối tượng. - Mô tả sự tương tác giữa các đối tượng.
  32. 32 Vẽ sơ đồ tƣơng tác nhƣ thế nào? Như chúng ta đã thảo luận từ trước mục đích của sơ đồ tương tác là để nắm bắt những diện mạo thay đổi của hệ thống. Vì vậy để nắm bắt những diện mạo thay đổi chúng ta cần hiểu cái gì là diện mạo động và nó được hình dung như thế nào. Diện mạo động có thể được định nghĩa như là chụp nhanh lại diện mạo của hệ thống đang chạy tại các thời điểm riêng biệt. Chúng ta có 2 loại sơ đồ tương tác trong UML. Một là sơ đồ trình tự và cái khác là sơ đồ cộng tác. Chúng ta cần phải xác định các things trước khi vẽ sơ đồ: - Các đối tương trong quá trình tương tác. - Các luồng thông báo giữa các đối tượng. - Trình tự trong đó các thông báo được truyền đi. - Tổ chức đối tượng. Ví dụ: Chúng ta thực hiện vẽ sơ đồ tương tác cho bài toán hệ thống quản lý đơn đặt hàng. Sơ đồ vẽ đầu tiên là sơ đồ trình tự và thứ 2 là sơ đồ cộng tác. Sơ đồ trình tự: Đối với sơ đồ trình tự sẽ có 4 đối tượng cần quan tâm (Customer, Order, SpecialOrder và NormalOrder). Đầu tiên, khách hành sẽ gửi một đơn đặt hàng tới đối tượng Order. Đối tượng sẽ gửi một lệnh xác nhận confirm() tới SpecialOrder. Đối tượng SpecialOrder sẽ gửi một lệnh Dispatch() tới chính nó. Sơ đồ cộng tác: Biểu đồ này biểu diễn cách tổ chức các đối tượng
  33. 33 4.2.7. Sơ đồ statechart Mục đích của việc sử dụng sơ đồ Statechart là miêu tả các trạng thái khác nhau của một thành phần trong hệ thống. Các trạng thái là là riêng biệt, cụ thể đối với một thành phần, đối tượng của một hệ thống Việc sử dụng sơ đồ statechart cũng thể hiện được các trạng thái của từng thành phần, đối tượng trong hệ thống được điều khiển bởi các sự kiện trong và ngoài hệ thống như thế nào. Mục đích: Sơ đồ trạng thái là một trong 5 sơ đồ UML được dùng để xây dựng lên tính năng động của một hệ thống. Sơ đồ trạng thái định nghĩa các trạng thái khác nhau của một đối tượng trong suốt vòng đời của nó. Và những trạng thái này được thay đổi bởi các sự kiện. Vì vậy, sơ đồ trạng thái rất hữu ích trong việc xây dựng lên hệ thống tác động trở lại. Hệ thống tác động trở lại có thể được định nghĩa như là một hệ thống mà đáp trả lại các sự kiện bên ngoài và bên trong. Sơ đồ trạng thái mô tả luồng điều khiển từ trạng thái đầu tiên tới trạng thái khác. Các trạng thái được định nghĩa nuhư là một điều kiên trong đó một đối tượng tồn tại và đối tượng đó thay đổi khi một vài sự kiện được gây ra. Vì vậy mục đích quan trọng nhất của sơ đồ trạng thái là xây dựng vòng đời của một đối tượng từ khi khởi tạo tới khi kêt thúc. Tóm lại, mục đích của sơ đồ trạng thái của thế mô tả tóm tắt như sau: - Để xây dựng diện mạo thay đổi của hệ thống. - Để xây dựng vòng đời của một hệ thống tương tác. - Mô tả các trạng thái khác nhau của đối tượng trong suốt thời gian sống của nó. - Định nghĩa trạng thái của bộ máy để xây dựng lên trạng thái của một đối tượng. Vẽ sơ đồ trạng thái nhƣ thế nào? Sơ đồ trạng thái được sử dụng để mô tả các trạng thái của các đối tượng khác nhau trong toàn bộ vòng đời của nó. Vì vậy, điểm nổi bật được đưa ra là trạng thái thay đổi dựa trên các sự kiện
  34. 34 trong và ngoài hệ thống. Trạng thái của các đối tượng đóng vai trò quan trọng trong việc phân tích và triển khai chúng một cách đúng đắn, chính xác. Trước khi vẽ một sơ đồ trạng thái chúng ta phải rõ ràng một số điểm sau: - Nhận biết các đối tượng quan trọng được phân tích. - Nhận biết các trạng thái. - Nhận biết các sự kiện. Ví dụ dưới đây mô tả sơ đồ trạng thái của đối tượng Order. Trạng thái đầu tiên là trạng thái khởi đầu mà từ đó tiến trình bắt đầu. Các trạng thái tiếp theo được đến từ các sự kiện như là send request, confirm request, và dispatch order. Những sự kiện này chịu trách nhiệm cho việc thay đổi trạng thái của đối tượng Order. Trong suốt toàn bộ vòng đời của hệ thống nó đi qua một chuỗi các trạng thái và có thể bị thoát không đúng quy trình. Việc thoát không đúng quy trình có thể xảy ra trong một vài trường hợp của hệ thống. Khi toàn bộ vòng đời được hoàn thành nó được xem như là hoàn thành một giao dịch. Sơ đồ trạng thái của đối tượng Order được mô tả như hình dưới đây: 4.2.8. Sơ đồ hoạt động Sơ đồ hoạt động là một sơ đồ quan trọng khác trong UML để mô tả hiện mạo thay đổi của hệ thống. Sơ đồ hoạt động cơ bản là một luồng biểu đồ biểu diễn luồng bắt đầu từ hoạt động đầu tiên tới hoạt động khác. Hoạt động này có thể được mô tả như là hoạt động của hệ thống. Vì vậy điều khiển luồng được vẽ từ môt thao tác tới thao tác khác. Sơ đồ hoạt động giải quyết tất cả các luồng điều khiển bằng việc sử dụng các thành phần như là fork, join Mục đích:
  35. 35 Sơ đồ hoạt động không chỉ sử dụng cho việc cung cấp cái nhìn trực quan về hệ thống mà còn được sử dụng để xây dựng lên hệ thống có thể thực thi bằng việc chuyển tiếp và đảo ngược. Mục đích của sơ đồ hoạt động có thể được tóm tắt như sau: - Vẽ luồng hoạt động của hệ thống. - Mô tả chuỗi từ một hoạt động với một hoạt động khác. - Mô tả luồng song song, nhánh và đồng thời của hệ thống. Vẽ sơ đồ hoạt động nhƣ thế nào? Sơ đồ hoạt động được sử dụng như là một flow chart bao gồm các hoạt động được thực hiện bởi hệ thống. Nhưng sơ đồ hoạt động không chính xác là một flow chart. Trước khi vẽ một sơ đồ hoạt động chúng ta phải hiểu rõ về các phần tử được sử dụng trong sơ đồ hoạt động. Phần tử chính của một sơ đồ hoạt động là hoạt động của bản thân nó. Một hoạt động là một chức năng được thực hiện bởi hệ thống. Sau khi xác định các hoạt động chúng ta cần hiểu chúng kết hợp với các rằng buộc và điều kiện như thế nào. Như vậy khi vẽ sơ đồ hoạt động chúng ta phải xác định được các phần từ sau: - Các hoạt động. - Liên kết, kết hợp - Các điều kiện - Các giàng buộc. Sơ đồ dưới đây được vẽ với 4 hoạt động chính. - Gửi đơn đặt hàng tới khách hàng. - Nhận đơn đặt hàng. - Xác nhận đơn - Gửi đơn đặt hàng đi. Sau khi nhận được đơn đặt hàng, điều tra điều kiện được thực hiện để kiểm tra xem đơn đặt hàng là 1 trong 2 loại normal hay special order. Sau khi loại đơn đặt hàng được xác định hành động gửi đi được thực hiện và được xem như là kết thúc một tiến trình hoạt động.
  36. 36 Bài tập 1) Biểu đồ lớp là gì? Mục đích và cách vẽ biểu đồ lớp (Class diagram)? 2) Biểu đồ đối tượng là gì? Mục đích và cách vẽ biểu đồ đối tượng (Object diagram)? 3) Biểu đồ Use case là gì? Mục đích và cách vẽ biểu đồ Use case? 4) Biều đồ tuần tự là gì? Mục đích và cách vẽ biểu đồ tuần tự (Sequence diagram)?
  37. 37 CHƢƠNG V: QUY TRÌNH PHÂN TÍCH VÀ THIẾT KẾ 5.1. Nền tảng Phân tích yêu cầu là công việc bao gồm các tác vụ xác định các yêu cầu cho một hệ thống mới hoặc được thay đổi, dựa trên cơ sở là các yêu cầu (có thể mâu thuẫn) mà những người có vai trò quan trọng đối với hệ thống, chẳng hạn người sử dụng, đưa ra. Việc phân tích yêu cầu có ý nghĩa quan trọng đối với thành công của một dự án. Việc phân tích yêu cầu một cách có hệ thống còn được gọi là kỹ nghệ yêu cầu (requirements engineering). Đôi khi nó còn được gọi một cách không thật chính xác bằng những cái tên như thu thập yêu cầu (requirements gathering, requirements capture), hoặc đặc tả yêu cầu (requirements specification). Thuật ngữ "phân tích yêu cầu" còn được áp dụng cụ thể cho công việc thuần túy phân tích (thay vì các việc khác chẳng hạn như làm rõ yêu cầu hay viết tài liệu yêu cầu). Tùy theo mức độ phức tạp của phần mềm làm ra, người thiết kế phần mềm sẽ ít nhiều dùng đến các phương tiện để tạo ra mẫu thiết kế theo ý muốn (chẳng hạn như là các sơ đồ khối, các lưu đồ, các thuật toán và các mã giả), sau đó mẫu này được mã hoá bằng các ngôn ngữ lập trình và đưọc các trình dịch chuyển thành các khối lệnh (module) hay/và các tệp khả thi. Tập hợp các tệp khả thi và các khối lệnh đó làm thành một phần mềm. Thường khi một phần mềm được tạo thành, để cho hoàn hảo thì phần mềm đó phải đưọc điều chỉnh hay sửa chữa từ khâu thiết kế cho đến khâu tạo thành phiên bản phần mềm một số lần. Một phần mềm thông thường sẽ tương thích với một hay vài hệ điều hành, tùy theo cách thiết kế, cách viết mã nguồn và ngôn ngữ lập trình được dùng. 5.2. Quy trình vĩ mô: Vòng đời của triển khai phần mềm Mục đích của quy trình vĩ mô là để hướng dẫn toàn bộ triển khai hệ thống. Một cách cơ bản là để hướng dẫn tạo ra hệ thống. Phạm vi của quy trình vĩ mô là từ một ý tưởng ban đầu của hệ thống phần mềm mà thực hiện triển khai ý tưởng đó. 5.2.1. Quy trình vĩ mô theo nội dung Quy trình vĩ mô theo nội dung bao gồm một số các giai đoạn sau: - Yêu cầu (Requirements): Thiết lập và duy trì sự thỏa thuận với các khách hàng và các nhà đầu tư khác trên những gì hệ thống nên làm. Thiết lập giới hạn của hệ thống. - Phân tích và thiết kế: Biến đổi những yêu cầu trong thiết kế hệ thống, cái mà phục vụ như là một đặc tả của sự thi hành trong môi trường thi hành đã chọn. - Thi hành (Implementation): thi hành, kiểm tra và tích hợp hệ thống, kết quả một hệ thống có thể thực thi.
  38. 38 - Kiểm định: Kiểm định thực thi để đảm bảo rằng đã hoàn thành các yêu cầu. Xác nhận thông qua các bản demo mà phần mềm thực hiện các chức năng như đã thiết kế. - Triển khai: Đảm bảo rằng sản phẩm phần mềm là sẵn sàng cho người dùng cuối của nó. Các quy tắc sau sẽ được thực hiện qua vòng đời của phần mềm - Quản lý dự án: Quản lý dự án phát triển phần mềm, bao gồm: lên kế hoạch, phục vụ và giám sát dự án cũng như quản lý rủi ro. - Quản lý cấu hình và sự thay đổi: Xác định cấu hình các mục, điều khiển sự thay đổi của các mục đó và quản lý cấu hình của các mục đó. - Môi trường: Cung cấp môi trường phát triển phần mềm bao gồm cả các quy trình và công tụ mà hỗ trợ cho đội triển khai. 5.2.2. Quy trình vĩ mô theo thời gian – Mốc và giai đoạn a. Giai đoạn bắt đầu (Inception): Mục đích: Mục đích của giai đoạn khởi đầu là đảm bảo rằng dự án có tính ứng dụng và khả thi. Hoạt động: Trong suốt giai đoạn Khởi đầu, bạn thiết lập và ưu tiên những yêu cầu cốt yếu của hệ thống, đạt được thỏa thuận với khách hàng trên những gì được xây dựng, đảm bảo rằng bạn hiểu và nắm được những rủi ro kèm theo việc xây dựng một hệ thống và quyết định môi trường triển khai nào được sử dụng (gồm cả quy trình và công cụ).
  39. 39 Sản phẩm (Work Products): Sản phẩm chính của giai đoạn khởi đầu là tầm nhìn về những gì được xây dựng, các thuộc tính hành vi, một danh sách rủi ro, xác định kiểu kiến trúc kĩ thuật và môi trường phát triển. Tầm nhìn cung cấp một cách mô tả rõ ràng về những gì được xây dựng bao gồm phạm vi của nó, đặc trưng, ảnh hưởng qua lại và quan hệ với các hệ thống đã tồn tại cũng như là bất kì các rằng buộc phải được theo dõi, xem xét. Mốc (Milestone): Phạm vi được hiểu. Giai đoạn Khởi tạo được hoàn thành khi có sự hiểu rõ ràng về những gì được xây dựng (toàn bộ phạm vi và các yêu cầu chính của hệ thống), hiểu rõ sự ưu tiên của các yêu cầu liên quan. b. Chi tiết bổ sung (Elaboration): Mục đích: Điều đầu tiên đó là những gì cần xây dựng phải được hiểu và đạt được sự đồng ý, chấp thuận. Hoạt động: Giai đoạn Elaboration bao gồm việc quyết định đưa ra kiến trúc, thiết lập phần nền tảng của kiến trúc, triển khai phần cốt lõi, kiểm định và tinh chỉnh nền tảng xây dựng hệ thống dựa trên kết quả của việc kiểm định. Sản phẩm (Work Product): Trong suốt giai đoạn Elaboration, kiến trúc được phê duyệt bằng việc tao ra một chuỗi kiến trúc có thể thực thi. Kết quả của giai đoạn Elaboration không chỉ cung cấp một tài liệu về kiến trúc mà còn bao gồm những ấn phẩm thực tế của hệ thống. Mốc: Giai đoạn Elaboration được hoàn thành khi kiến trúc được xác lập tính hợp lệ với tất cả các yêu cầu của hệ thống và về chức năng và không chức năng, và khi tất cả các rủi ro đã được giảm bớt để xác định giá và lịch biểu cho quá trình triển khai hệ thống. c. Xây dựng (Construction) Mục đích: Xây dựng một kiến trúc ổn định, tập trung vào việc chuyển từ hiểu vấn đề và xác định những giải pháp chính tới việc triển khai một sản phẩm có thể triển khai. Hoạt động: Trong suốt giai đoạn xây dựng, việc phát triển hệ thống được hoàn thành dựa trên kiến trúc cơ sở được xây dựng từ giai đoạn trước. Sản phẩm: Trong suốt giai đoạn này, một chuỗi các ấn bản có thể thực thi được đưa ra đáp ứng những kịch bản, yêu cầu của người dùng cuối. Mốc: Hệ thống sẵn sàng cho người dùng cuối kiểm tra: Giai đoạn xây dựng hoàn thành khi các chức năng và chất lượng của các ấn bản là cần thiết để triển khai tới người dùng cuối cho một số người dùng cuối khác kiểm tra. d. Chuyển giao. Mục đích: Giai đoạn chuyển giao được thực hiện khi bạn chắc chắn sản phẩm có thể được chấp nhận bởi người dùng cuối. Hoạt động: Trong suốt giai đoạn chuyển tiếp, sản phẩm được cung cấp tới người dùng cho việc đánh giá và kiểm định. Sau đó nhóm triển khai thu thập những phản hồi của người dùng. Trong giai đoạn này chủ yếu tập chung vào làm cho chương trình khớp với yêu cầu,
  40. 40 thiết lập cấu hình, cài đặt và hướng dẫn sử dụng. Các tài liệu hỗ trợ dùng chương trình được hoàn thiện và gửi cho người dùng cuối. Sản phẩm: Sản phẩm được đưa ra trong suốt giai đoạn chuyển giao bao gồm sản phẩm đóng gói, tài liệu hỗ trợ, tài liệu hướng dẫn. Mốc: Hệ thống sẵn sàng cho việc triển khai. 5.2.3. Quy trình vĩ mô theo thời gian – Lặp đi lặp lại Trong quy trình vĩ mô, các mốc đạt được bằng việc thực hiện 1 hoặc nhiều lần lặp lại và những lần lặp lại này có thể bao gồm các hoạt động trong bất kì vào trong toàn bộ quy tắc. Tuy nhiên, thời gian lặp lại sử dụng trong các quy tắc khác nhau phụ thuộc vào xuất hiện trong giai đoạn lặp nào. Nếu quá trình lặp lại được thực hiện trong giai đoạn khởi đầu, phần lớn thời gian sẽ được sử dụng trên việc xử lý các yêu cầu. Nếu quá trình lặp lại được thực hiện trong giai đoạn chi tiết, phần lớn thời gian sẽ được sử dụng trên việc phân tích và thiết kế. Nếu quá trình lặp lại được thực hiện trong giai đoạn xây dựng thì phần lớn thời gian được sử dụng trên việc triển khai và kiểm định. Tất nhiên, đối với một số disciplines, như là cấu hình và thay đổi quan lý, môi trường, quản lý dự án, được thực hiện thông qua vòng đời của chương trình. Hình trên miêu tả một dự án di chuyển thông qua một chuỗi quá trình được lặp đi lặp lại. Kích thước của các hộp trong mỗi giai đoạn biểu thị lượng thời gian được sử dụng trên giai đoạn đó. 5.3. Quy trình vi mô: Quá trình phân tích và thiết kế Như hình mô tả dưới đây, quá trình phân tích và thiết kế hệ thống được thực hiện trong toàn bộ quá trình phát triển phần mềm. Quá trình vĩ mô cung cấp đầu vào cho quá trình vi mô và sử dụng đầu ra của quá trình vi mô. Đặc biệt quá trình vi mô lấy yêu cầu được cung cấp bởi quá trình vĩ mô và sản xuất ra đặc tả thiết kế mà đã được thực hiên, kiểm thử và triển khai trong quá trình vĩ mô.
  41. 41 Chúng ta đã mô tả quá trình vĩ mô trong 2 lĩnh vực đó là thời gian và nội dung, ở đây chúng ta cũng sẽ mô tả quá trình vi mô trong 2 lĩnh vực đó là khái niệm và nội dung. 5.3.1. Mức độ trìu tƣợng, khái niệm Trong quá trình vi mô, các giai đoạn phổ biến, truyền thống của phân tích và thiế kế là tập trung vào việc làm mờ và thay thế được thực hiện tại các mức độ khác nhau của trìu tượng. Phân tích lấy các yêu cầu của hệ thống và đưa ra một giải pháp ban đầu, và thiết kế lấy kết quả của quá rình phân tích và đưa ra một đặc tả mà có hiệu quả trong việc thực hiện. Việc phân tích được xem như là hoàn thành khi nó biểu diễn đúng đắn, chính xác các yêu cầu của hệ thống, là phù hợp và có thể phục vụ tốt cho việc thiết kế. Việc thiết kế được xem như là hoàn thành khi nó mô tả chi tiết đủ để thực hiện và kiểm định. Phân tích tập trung vào hành vi chứ không phải cấu tạo. Trong phân tích, bạn tìm đến xây dựng một thế giới bằng việc xác định các phần tử mà tạo nên các vấn đề trong hệ thống và mô tả chức năng của chúng, trách nhiệm và sự cộng tác. Trong thiết kế, bạn sáng tạo ra các phần tử mà cung cấp các hành vi mà các phần tử trong giai đoạn phân tích yêu cầu. Bạn bắt đầu quá trình thiết kế ngay khi bạn hoàn thành việc xây dựng mô hình các hành vi của hệ thống. Phân tích và thiết kế được thực hiện tại các mức của trìu tượng qua vòng đời phát triển. Số mức không thể xác định, nó phụ thuộc vào phạm vi của hệ thống.
  42. 42 Các hành động Quá trình vi mô bao gồm một tập các hành động, mà được thực hiện cho phạm vi xác định và tại mức độ trìu tượng xác định. - Xác định các phần tử? Tìm hiểu, khám phá hoặc đề xuất các phần tử sẽ sử dụng. - Định nghĩa sự kết hợp giữa các phần tử: Mô tả các phần tử kết hợp với nhau như thế nào để cung cấp các hành vi mà hệ thống yêu cầu. - Định nghĩa các mối quan hệ giữa các phần tử. Định nghĩa các mối quan hệ giữa các phần tử, hỗ trợ cho sự kết hợp các phần tử. - Định nghĩa semantic của các phần tử: Thiết lập các hành vi và các thuộc tính của các phần tử, chuẩn bị các phần tử cho mức độ trìu tượng tiếp theo. Các hoạt động của quá trình vi mô được mô tả bởi hình sau: Sản phẩm Có 2 sản phẩm chính sẽ được sinh ra trong quá trình vi mô: - Mô tả kiến trúc: Mô tả kiến trúc của hệ thống, bao gồm cả việc miêu tả kĩ thuật chung. Việc mô tả bao gồm cấu trúc cần thiết cho diện mạo của mô hình phân tích và thiết kế.
  43. 43 - Mô hình phân tích thiết kế bao gồm các phần tử phân tích thiết kế của giải pháp phần mềm và việc tổ chức chúng, cũng như các mối quan hệ mà miêu tả hành vi yêu cầu của hệ thống được thực hiện như thế nào trong các phần tử đó. Quá trình vi mô và mức độ trừu tƣợng Quá trình vi mô áp dụng như nhau đối với kiến trúc sư dự án và kĩ sư ứng dụng, sự khác biệt đó là mức độ trìu tượng được đề cập. Từ góc nhìn của kiến trúc sư, quá trình vi mô cung cấp một khuôn mẫu cho phát triển và khám phá kiến trúc thay thế. Từ quan điểm của kĩ sư, quá trình vi mô cung cấp các hướng dẫn trong việc ra quyết định thích ứng với từng kiểu cấu trúc. Khi thực hiện phân tích kiến trúc, quá trình vi mô tập trung vào việc tạo một phiên bản ban đầu của kiến trúc, những kiến trúc này thúc đẩy các kiến trúc đã tồn tại hoặc các kiến trúc nền tảng ban đầu. Trong quá trình thiết kế kiến trúc, kiến trúc ban đầu được phát triển từ kiến trúc phân tích mà đã được lọc, lựa chọn dựa trên những kinh nghiệm trong suốt quá trình phân tích kiến trúc. Quá trình vi mô tập trung vào việc chọn lọc các phần tử đã được phân tích rõ ràng, các phần tử thiết kế và trách nhiệm của chúng. Các phần tử thiết kế được định nghĩa tại mức độ này biểu diễn các khối chính của toàn bộ kiến trúc nền tảng và các mối quan hệ của chúng xác định toàn bộ cấu trúc của hệ thống. Các kĩ thuật phân tích cũng được chọn lựa vào trong kĩ thuật thiết kế mà thúc đẩy các công nghệ trước đó. Việc sử dụng lại cũng đóng vai trò quan trọng. Trong thành phần phân tích, quá trình vi mô tập trung vào việc phân tích các phần tử xác định và trách nhiệm cũng như là tương tác giữa chúng. Việc phân tích các phần tử này miêu tả gần đúng các thành phần của hệ thống mà được sử dụng trong quá trình thiết kế thành phần dể xác định việc thiết kế các phần tử. Trong thành phần thiết kế, quá trình vi mô tập trung vào việc chọn lọc việc thiết kết các thành phần bằng việc định nghĩa nó trong các lớp mà có thể thực thi trực tiếp bằng các kĩ thuật thực hiện đã chọn. Trong suốt quá trình thiết kế chi tiết, bạn tiếp tục chọn lựa các lớp thông qua làm việc với các nội dung, hành vi và quan hệ của chúng. Quá trình chọn lựa nên dừng lại khi có đủ chi tiết cho việc thiết kế các lớp được thực thi. Bài tập 1) Trình bày quy trình xây dựng phần mềm? 2) Trình bày quy trình phân tích và thiết kế trong xây dựng phần mềm?
  44. 44 CHƢƠNG VI: ÁP DỤNG PHÂN TÍCH BÀI TOÁN CỤ THỂ 6.1. Hệ thống điều khiển: Quản lý hệ thống giao thông Khởi đầu Ở một số nước tiên tiến thì việc sử dụng hệ thống xe lửa được coi như là phổ biến. Người dân vẫn thích sử dụng hệ thống xe lửa để đi lại những cung đường dài. Hơn nữa, việc sử dụng xe lửa đi lại cũng được coi như là phương tiện an toàn nhất trong các phương tiện đường bộ. Chúng ta có thể thấy rằng hệ thống xe lửa ở các nước phát triển rất mạnh bởi vì nó mang lại hiệu quả kinh tế cao hơn so với các phương tiện khác. Vì vậy, đối với một hệ thống xe lửa cần phải được giám sát chặt chẽ, bởi vì mỗi chuyến sức vận chuyển có nó có thể lên tới hàng trăm thậm chí hàng ngàn người. Trong bài này chúng ta tập phân tích một hệ thống quản lý đường xe lửa bằng việc xác định các yêu cầu và hệ thống tác nhân. Yêu cầu cho hệ thống quản lý tuyến đƣờng xe lửa: Hệ thống quản lý tuyến đường xe lửa có 2 chức năng chính: Dẫn đường và giám sát tuyến đường. Các chức năng liên quan bao gồm lập kế hoạch, dự báo lỗi, theo dõi vết tuyến đường, giám sát giao thông, tránh va chạm, xung đột tuyến đường và ghi lại nhật ký. Từ những chức năng trên, chúng ta có thể đưa ra 8 use cases sau: - Route Train: Thiết lập một kế hoạch, kế hoạch này vạch rõ các tuyến đường mà xe lửa sẽ đi qua. - Plan Traffice: Thiết lập một kế hoạch giao thông mà cung cấp hướng dẫn trong việc triển khai kế hoạch tuyến xe lửa tại một thời gian nhất định và một vùng nhất định. - Monitor Train Systems: Giám sát hệ thống xe lửa cho nhưng chức năng thích hợp. - Predict Failure: Thực hiên phân tích những điều kiện của hệ thống và đưa ra những cảnh báo lỗi liên quan tới kế hoạch vận hành của từng tuyến xe lửa. - Track Train Location: Giám sát vị trí của các xe lửa. - Monitor Traffic: Giám sát tất cả các tuyến xe lửa trong một vùng. - Avoid Collision: Đưa ra biện pháp, có thể là tự động hoặc làm thủ công để tránh những vụ va chạm trên tuyến xe lửa. - Log Maintenance: Đưa ra biện pháp để ghi lại những nhật kí đã thực hiện trên tuyến xe lửa. Những use cases này thiết lập các yêu cầu chức năng cơ bản cho hệ thống quản lý giao thông xe lửa. Chúng cho ta biết hệ thống phải làm những gì đối với người sử dụng nó. Thêm vào đó chúng ta
  45. 45 có những yêu cầu không có chức năng và giằng buộc mà tác động lên các yêu cầu được định rõ bởi các use case của chúng ta: Những yêu cầu không có chức năng: - Vận chuyển hành khách và hàng hóa an toàn. - Hỗ trợ tốc độ xe lửa lên tới 250 dặm/giờ. - Cung cấp một hệ thống hoạt động chính xác ở mức 99.99% - Cung cấp các đầy đủ các chức năng, trách dư thừa. - Cung cấp vị trí chính xác của tàu trong vòng 10 yards. - Cung cấp chính xác vận tốc của xe lửa. - Đáp ứng đầu vào trong vòng 10s. Những ràng buộc. - Đáp ứng các tiêu chuẩn quốc gia - Phù hợp về giá thành cả về phần cứng và phần mềm. Bây giờ chúng ta đã có những yêu cầu của bài toán. Quay lại bài toán quản lý hệ thống đường xe lửa của chúng ta. Qua tìm hiểu và phân tích thì chúng ta có thể đưa ra 3 kiểu người dùng khác nhau tác động tới hệ thống: Dispatcher, TrainEngineer, và Maintainer. Ngoài ra hệ thống còn giao tiếp, tương tác với thiết bị ngoài, Navstar GPS. Các tác nhân đóng vai trò sau trong hệ thống. - Dispatcher: Thiết lập tuyến đường xe lửa và theo dõi việc tiến hành của từng xe lửa riêng biệt. - TrainEngineer: Giám sát tình trạng hoạt động của xe lửa. - Maintainer: Giám sát tình trạng duy tri hệ thông xe lửa. - Navstar GPS: Cung cấp dịch vụ định vị dùng để theo dõi tàu hỏa.
  46. 46 6.2. Ứng dụng Web: Hệ thống theo dõi kì nghỉ Ngày nay, đối với nhiều doanh nghiệp, sự tự chủ và độc lập của công nhân ngày càng tăng. Mỗi công nhân có thể tham gia vào nhiều dự án vì thế phải phân chia thời gian sao cho hợp lý. Tương ứng với số thời gian làm việc thì đòi hỏi thời gian nghỉ ngơi cũng phải hợp lý. Vì vậy, các nhà quản lý có ít thời gian gặp được công nhân, do đó việc quản lý thời gian làm việc cũng như thời gian nghỉ gặp nhiều khó khăn. Giải pháp được đưa ra là chúng ta xây dựng một hệ thống cho phép theo dõi thời gian làm việc cũng như kì nghỉ của mỗi công nhân. Khởi đầu Yêu cầu của hệ thống là được miêu tả một cách tóm tắt các tài liệu, các đặc tính chủ yếu, các mô hình use case, các đặc tả use case chính và các kiến trúc cần thiết. Yêu cầu:
  47. 47 Hệ thống theo dõi kì nghỉ sẽ cung cấp từng nhân viên riêng biệt cùng với khả năng để quản lý thời gian nghỉ của họ, nghỉ việc vì đau ốm, và thời gian nghỉ thương niên. Hệ thống sẽ cung cấp các đặc tính chính sau: - Thực thi một cách linh hoạt cho việc kiểm chứng và xác minh lại thời gian yêu cầu. - Cho phép quản lý phê duyệt. - Cho phép người dùng có thể truy cập lại thời gian trước đó và cho phép yêu cầu được thực hiên đến một năm rưỡi trong tương lai. - Sử dụng e-mail thông báo để yêu cầu quản lý phê duyệt và thông báo cho nhân viên biết trạng thái thay đổi. - Sử dụng phần cứng hiện tại. - Được thực hiện, triển khai mở rộng của mạng nội bộ hiện tại và sử dụng tính năng đăng nhập một lần cho tất cả các cơ chế xác thực. - Lưu giữ lại những bản ghi cho tất cả các giao dịch. - Cho phép người quản lý trực tiếp tặng thời gian nghỉ thêm cho nhân viên. - Cung cấp một dịch vụ giao diện Web cho các hệ thống nội bộ khác truy vấn và đưa ra bất kỳ thời gian nghỉ của nhân viên nào. Mô hình use case mức cao nhất chưa 4 tác nhân và 8 use case được miêu tả ở hình dưới đây: Nhìn vào sơ đồ trên, chúng ta thấy có 4 tác nhân sau; - Employee: là người sử dụng hệ thống chủ yếu. Một nhân viên sử dụng hệ thống để quản lý thời gian nghỉ của họ.
  48. 48 - Manager: là một nhân viên cũng sử dụng hệ thống như các nhân viên khác với mục đích tương tự nhưng có thêm một số quyền cao hơn nhân viên bình thường. Có thể quản lý thời gian gian nghỉ của một nhóm nhân viên. - Clerk: Một thành viên của hệ thống quản lý người có đầy đủ các quyền để xem hồ sơ, dữ liệu cá nhân của một nhân viên và chịu trách nhiệm cho tất cả các thông tin về nhân viên. Một thư ký có thể thêm hoặc loại bỏ bất kỳ một bản ghi nào trong hệ thống. - System Admin: Có vai trò chịu trách nhiệm cho hệ thống chạy ổn định, trơn, không bị lỗi Sơ đồ trên còn mô tả các use case chính sau: - Manage Time: Miêu tả các nhân viên yêu cầu và xem thời gian nghỉ như thế nào. - Approve Request: Miêu tả một quản lý đáp ứng yêu cầu của một nhóm như thế nào. - Edit Employee Record: Miêu tả một Clerk của hệ thống chỉnh sửa thông tin của một nhân viên như thế nào. - Manage Locations: Miêu tả một Clerk quản lý các bản ghi như thế nào. - Manage Leave Categories: - Override Leave Records: - Back Up System Logs. Miêu tả Admin sao lưu dữ liệu. Bài tập 1) Áp dụng phân tích và thiết kế hệ thống vào bài toán quản lý Hồ sơ sinh viên? 2) Áp dụng phân tích và thiết kế hệ thống vào bài toán quản lý Kết quả học tập của sinh viên?
  49. 49 MỘT SỐ ĐỀ THI MẪU
  50. 50 Trƣờng Đại Học Hàng Hải Việt Nam Khoa Công nghệ Thông tin BỘ MÔN HỆ THỐNG THÔNG TIN THI KẾT THÚC HỌC PHẦN Đề thi số: Ký duyệt đề: Tên học phần: PHÂN TÍCH& THIẾT KẾ HT HƢỚNG ĐỐI TƢỢNG Năm học: x x x Thời gian: 60 phút Câu 1: (2 điểm) So sánh Phân tích thiết kế hệ thống hướng cấu trúc với Phân tích thiết kế hệ thống hướng đối tượng? Câu 2: (2 điểm) Đối tượng là gì? Mối quan hệ giữa các đối tượng? Câu 3: (3 điểm) Trình bày các phương pháp phân loại? Lấy ví dụ? Câu 4: (3 điểm) Trình bày các khối cơ bản trong UML? HẾT Lưu ý: - Không sửa, xóa đề thi, nộp lại đề sau khi thi
  51. 51 Trƣờng Đại Học Hàng Hải Việt Nam Khoa Công nghệ Thông tin BỘ MÔN HỆ THỐNG THÔNG TIN THI KẾT THÚC HỌC PHẦN Đề thi số: Ký duyệt đề: Tên học phần: PHÂN TÍCH& THIẾT KẾ HT HƢỚNG ĐỐI TƢỢNG Năm học: x x x Thời gian: 60 phút Câu 1: (2 điểm) Trình bày những ưu và nhược điểm của Phân tích và thiết kế hệ thống hướng đối tượng? Câu 2: (2 điểm) Lớp là gì? Mối quan hệ giữa các lớp? Câu 3: (3 điểm) Liệt kê các loại biểu đồ (Diagrams) trong UML? Mục đích của từng loại biểu đồ? Câu 4: (3 điểm) Biểu đồ lớp là gì? Trình bày mục đích và cách vẽ biểu đồ lớp trong UML? HẾT Lưu ý: - Không sửa, xóa đề thi, nộp lại đề sau khi thi
  52. 52 Trƣờng Đại Học Hàng Hải Việt Nam Khoa Công nghệ Thông tin BỘ MÔN HỆ THỐNG THÔNG TIN THI KẾT THÚC HỌC PHẦN Đề thi số: Ký duyệt đề: Tên học phần: PHÂN TÍCH& THIẾT KẾ HT HƢỚNG ĐỐI TƢỢNG Năm học: x x x Thời gian: 60 phút Câu 1: (2 điểm) Đối tượng là gì? Lớp là gì? Trình bày mối quan hệ giữa Lớp và Đối tượng? Cho ví dụ? Câu 2: (2 điểm) Trình bày các khái niệm: Use case, Actor trong UML? Cho ví dụ? Câu 3: (3 điểm) Vòng đời của xây dựng phần mềm? Câu 4: (3 điểm) Biểu đồ tuần tự (Sequence) là gì? Trình bày mục đích và cách vẽ biểu đồ tuần tự trong UML? HẾT Lưu ý: - Không sửa, xóa đề thi, nộp lại đề sau khi thi