II. PHÂN TÍCH THIẾT KẾ HƯỚNG ĐỐI TƯỢNG

II.1.Phương pháp phân tích thiết kế hướng đối tượng

Phân tích thiết kế hướng đối tượng là tập các quá trình và thao tác để tìm và khám phá cách có thể giải quyết bài toán phần mềm.

Phương pháp phân tích thiết kế hướng đối tượng là xây dựng một tập các lớp đối tượng tương ứng với các chức năng khác nhau, đáp ứng yêu cầu của bài toán đặt ra. Phương pháp này tiến hành theo 2 pha chính:

Pha phân tích: Chuyển đổi yêu cầu bài toán từ ngôn ngữ tự nhiên sang ngôn ngữ mô hình.

Pha thiết kế: Chuyển đổi đặc tả bài toán dưới dạng ngôn ngữ tự nhiên sang một mô hình cụ thể có thể cài đặt được.

Hai pha phân tích và thiết kế này bao gồm nhiều bước khác nhau:

Bước 1: Mô tả bài toán

Bài toán ban đầu được mô tả dưới dạng ngôn ngữ tự nhiên, bao gồm:

§  Mục đích, chức năng chung

§  Các yêu cầu về thông tin dữ liệu

§  Các yêu cầu về chức năng thực hiện

Bước 2: Đặc tả yêu cầu

Các yêu cầu được hình thức hóa lên một mức cao hơn bằng cách sử dụng ngôn ngữ kiểu kịch bản  để mô tả. Một kịch bản bao gồm:

§  Các tác nhân tham gia vào kịch bản.

§  Vai trò của mỗi tác nhân trong kịch bản.

§  Thứ tự các hành động mà mỗi tác nhân thực hiện: khi nào thực hiện, tác động vào tác nhân nào, thông tin nào được trao đổi.

Bước 3: Trích chọn đối tượng

Đề xuất các đối tượng có thể có mặt trong hệ thống:

§  Dựa vào các kịch bản được mô tả trong bước 2, chọn ra tác nhân có thể xuất hiện để đề xuất thành đối tượng.

§  Lựa chọn các đối tượng bằng cách loại bỏ các tác nhân bên ngoài hệ thống, các tác nhân trùng lặp.

§  Cuối cùng ta thu thập các đối tượng của hệ thống.

Bước 4: Mô hình hóa lớp đối tượng

Ta tiến hành trừu tượng hóa đối tượng thành các lớp:

§  Thu thập tất cả các thuộc tính  của mỗi đối tượng vừa thu thập được, dựa vào yêu cầu về thông tin trong yêu cầu hệ thống.

§  Thu thập các hành động mà mỗi đối tượng cần thực hiện, dựa vào các kịch bản mà đối tượng tương ứng có tham gia.

§  Nhóm các đối tượng tương tự như nhau, hoặc có nhiều thuộc tính gần giống nhau.,

§  Loại bỏ một số thuộc tính cá biệt, riêng tư của một số đối tượng trong nhóm.

§  Mô hình mỗi nhóm đối tượng còn lại thành lớp: Các thuộc tính chung của các đối tượng thành thuộc tính của lớp, các hành động của các đối tượng thành  phương thức của lớp.

Kết quả là ta thu được một tập các lớp đối tượng ban đầu của hệ thống.

Bước 5: Thiết kế tổng quát

Thiết kế mối quan hệ giữa các lớp trong hệ thống:

Xác định sơ đồ thiết kế giữa các lớp nếu có. Nếu hai lớp có một số thuộc tính chung thì tách các thuộc tính chung làm thành một lớp cơ sở, và hai lớp ban đầu đều dẫn xuất từ lớp cơ sở đó. Thông thường, lớp các trừu tượng sẽ làm lớp cơ sở, lớp càng cụ thể, càng chi tiết sẽ làm lớp dẫn xuất.

Bước 6: Thiết kế chi tiết

Thiết kế kiến trúc bên trong của mỗi lớp đối tượng:

§  Tổ chức dữ liệu của lớp theo các thuộc tính. Quy định phạm vi truy nhập cho từng thuộc tính.

§  Thiết kế chi tiết cách cư xử của lớp đối tượng thông qua các phương thức của lớp: Xác định kiểu dữ liệu trả về, kiểu tham số  của phương thức, mô tả thuật toán chi tiết cho từng phương thức, nếu cần.

Kết quả ta thu được một tập các lớp với thiết kế chi tiết kiến trúc bên trong.

Như vậy sau các bước phân tích thiết kế hướng đối tượng ta thu được một mô hình hệ thống đối tượng chi tiết. Sau pha phân tích và thiết kế hướng đối tượng, ta thu được đặc tả hệ thống dưới dạng mô hình các lớp: quan hệ giữa các lớp và kiến trúc bên trong của mỗi lớp. Đây sẽ là đầu vào cho pha tiếp theo: pha lập trình hướng đối tượng.

II.2. Các giai đoạn trong việc xây dựng phần mềm hướng đối tượng

II.2.1. Lập kế hoạch

Tiến hành khảo sát tổng quan hệ thống, vạch ra các vấn đề tồn tại trong hệ thống và các cơ hội của hệ thống. Ta phải xác định phạm vi của hệ thống đề xuất, trưởng dự án và nhóm phân tích viên ban đầu của hệ thống. Kế hoạch này xác định thời gian và nguồn lực cần thiết. Đánh giá khả thi của dự án, chi phí cần phải đầu tư và lợi ích mang lại. Kết quả của giai đoạn này là xác định được dự án hoặc được chấp thuận để phát triển, hoặc bị từ chối, hoặc phải định hướng lại.

II.2.2. Xác định mục tiêu

Gồm các bước sau:

§  Thu thập yêu cầu hệ thống

§  Nghiên cứu yêu cầu và cấu trúc hóa để nhận biết loại bỏ yếu tố dư thừa.

§  Phát sinh các phương án thiết kế chọn lựa phù hợp với yêu cầu và so sánh với nhau để chọn lựa phương án phù hợp nhât.

Giai đoạn này ta quan tâm đến mức độ trừu tượng hóa đầu tiên bằng cách xác định lớp và đối tượng đóng vai trò quan trọng nhằm diễn đạt các yêu cầu cũng như mục tiêu hệ thống. Khái niệm usecase được dùng trong giai đoạn này nhằm biểu diễn chức năng hệ thống và sự tương tác với người dùng hệ thống. Các kích hoạt bản hoạt động lúc này sử dụng mô hình động (dynamic diagram) nhằm mô tả nội dung của usecase để làm rõ sự tương tác giữa các đối tượng, vai trò và sự cộng tác của các đối tượng trong hoạt động của usecase hệ thống.

II.2.3. Giai đoạn thiết kế

Đưa ra bản đặc tả chi tiết cho giai đoạn xây dựng hệ thống. Có thể chia kết quả của giai đoạn này thành 2 mức:

Thiết kế luận lý: đặc tả hệ thống ở mức độ trừu tượng hóa. Giai đoạn này chỉ tập chung để biểu diễn khía cạnh hành vi và tính năng của đối tượng hệ thống.

Thiết kế vật lý: chuyển đổi kết quả của thiết kế luận lý sang đặc tả trên phần cứng, phần mềm sẽ sử dụng và các kĩ thuật đã chọn để cài đặt hệ thống. Đặc tả trên máy tính, hệ quản trị cơ sở dữ liệu ,ngôn ngữ lập trình đã chọn,… Từ đó các lập trình viên, những người xây dựng hệ thống khác để lập trình xây dựng hệ thống.

II.2.4. Giai đoạn xây dựng

Các lớp của giai đoạn thiết kế sẽ được biến thành những dòng mã lệnh (code) cụ thể trong một ngôn ngữ lập trình hướng đối tượng.Khi tạo ra các mô hình phân tích và thiết kế trong UML, tốt nhất nên cố gắng né tránh việc ngay lập tức biến đổi các mô hình này thành các dòng code. Trong những giai đoạn trước, mô hình được sử dụng để dễ hiểu, dễ giao tiếp và tạo nên cấu trúc của hệ thống; vì vậy, vội vàng đưa ra những kết luận về việc viết code có thể sẽ thành một trở ngại cho việc tạo ra các mô hình chính xác và đơn giản. Giai đoạn xây dựng là một giai đoạn riêng biệt, nơi các mô hình được chuyển thành code.

II.2.5. Giai đoạn thử nghiệm

Một hệ thống phần mềm thường được thử nghiệm qua nhiều giai đoạn và với nhiều nhóm thử nghiệm khác nhau. Các nhóm sử dụng nhiều loại biểu đồ UML khác nhau sẽ làm nền tảng cho công việc của mình. Thử nghiệm đơn vị sử dụng biểu đồ lớp và đặc tả lớp, thử nghiệm tích hợp thường sử dụng biểu đồ thành phần và biểu đồ cộng tác, giai đoạn thử nghiệm hệ thống sử dụng biểu đồ Use case để đảm bảo hệ thống có phương thức hoạt động đúng như đã được định nghĩa từ ban đầu trong các biểu đồ này.

II.2.6. Giai đoạn cài đặt và bảo trì

Điều chỉnh hệ thống phù hợp với nhu cầu sử dụng, thay đổi các phát sinh:

-         Chức năng sử dụng chưa phù hợp tốt nhất với người sử dụng, khó dùng.

-         Các điều kiện và yêu cầu của người dùng hệ thống thay đổi.

-         Các lỗi phát sinh do quá trình kiểm tra còn xót lại

-         Nâng cấp phiên bản mới của hệ thống

Bảo trì hệ thống không nên xem như là một giai đoạn tách rời mà nên xem như là một sự lặp lại chu trình của những giai đoạn trước đòi hỏi phải được nghiên cứu đánh giá và cài đặt. Tuy nhiên nếu hệ thống cần có sự thay đổi quá lớn về hoạt động, hoặc nhu cầu đặt ra vượt quá khả năng giải quyết hoặc chi phí quá lớn thì yêu cầu về hệ thống mới được xác lập để thay thế hệ thống hiện tại một quy trình lại bắt đầu.

II.3. Phân tích thiết kế hướng đối tượng với UML

Ngôn ngữ mô hình hóa thống nhất (Unifield Modeling Language – UML) là một ngôn ngữ để biểu diễn mô hình theo hướng đối tượng được xây dựng bởi ba tác giả trên với chủ đích là:

- Mô hình hoá các hệ thống sử dụng các khái niệm hướng đối tượng.

- Thiết lập một kết nối từ nhận thức của con người đến các sự kiện.

- Giải quyết vấn đề về mức độ thừa kế trong các hệ thống phức tạp, có nhiều ràng buộc khác nhau.

- Tạo một ngôn ngữ mô hình hoá có thể sử dụng được bởi người và máy.

UML có thể được sử dụng trong nhiều giai đoạn, từ phát triển, thiết kế cho tới thực hiện và bảo trì. Vì mục đích chính của ngôn ngữ này là dùng các biểu đồ hướng đối tượng để mô tả hệ thống nên miền ứng dụng của UML bao gồm nhiều loại hệ thống khác nhau như:

- Hệ thống thống tin (Information System): Cất giữ, lấy, biến đổi biểu diễn thông tin cho người sử dụng.

- Hệ thống kỹ thuật (Technical System): Xử lý và điều khiển các thiết bị kỹ thuật như viễn thông, hệ thống quân sự, hay các quá trình công nghiệp.

- Hệ thống nhúng (Embeded System): Thực hiện trên phần cứng gắn vào các thiết bị như điện thoại di động, điều khiển xe hơi, …

- Hệ thống phân bố ( Distributed System): Được phân bố trên một số máy cho phép truyền dữ liệu từ nơi này đến nơi khác một cách dễ dàng như CORBA, COM/DCOM, hay Java Beans/RMI.

- Hệ thống Giao dịch (Business System): Mô tả mục đích, tài nguyên (con người, máy tính, …), các quy tắc (luật pháp, chiến thuật kinh doanh, cơ chế, …), và công việc hoạt động kinh doanh.

- Phần mềm hệ thống (System Software): Định nghĩa cơ sở hạ tầng kỹ thuật cho phần mềm khác sử dụng, chẳng hạn như hệ điều hành, cơ sở dữ liệu, giao diện người sử dụng.

Một số những thành phần chủ yếu của ngôn ngữ UML:

Hướng nhìn (view): Hướng nhìn chỉ ra những khía cạnh khác nhau của hệ thống cần phải được mô hình hóa. Một hướng nhìn không phải là một bản vẽ, mà là một sự trừu tượng hóa bao gồm các biểu đồ khác nhau. Các hướng nhìn này nối kết ngôn ngữ mô hình hóa với quy trình được chọn cho giai đoạn phát triển.

Biểu đồ (diagram): Biểu đồ là các hình vẽ miêu tả nội dung trong một hướng nhìn. UML có tất cả 9 loại biểu đồ khác nhau được sử dụng trong những sự kết hợp khác nhau để cung cấp tất cả các hướng nhìn của một hệ thống.

Phần tử mô hình hóa (model element): Các khái niệm được sử dụng trong các biểu đồ được gọi là các phần tử mô hình, thể hiện các khái niệm hướng đối tượng quen thuộc. Ví dụ như lớp, đối tượng, thông điệp cũng như các quan hệ giữa các khái niệm này, bao gồm cả liên kết, phụ thuộc, khái quát hóa.

Cơ chế chung: Cơ chế chung cung cấp thêm những lời nhận xét bổ sung, các thông tin cũng như các quy tắc ngữ pháp chung về một phần tử mô hình; chúng còn cung cấp thêm các cơ chế để có thể mở rộng ngôn ngữ UML cho phù hợp với một phương pháp xác định (một quy trình, một tổ chức hoặc một người dùng).

II.3.1. Hướng nhìn (view)

Một hệ thống thường được miêu tả trong một loạt các hướng nhìn khác nhau, mỗi hướng nhìn sẽ thể hiện một bức ảnh ánh xạ của toàn bộ hệ thống và chỉ ra một khía cạnh riêng của hệ thống.

 Các View trong UML

Mỗi một hướng nhìn được miêu tả trong một loạt các biểu đồ, chứa đựng các thông tin nêu bật khía cạnh đặc biệt đó của hệ thống. Trong thực tế khi phân tích và thiết kế rất dễ xảy ra sự trùng lặp thông tin, cho nên một biểu đồ trên thật tế có thể là thành phần của nhiều hướng nhìn khác nhau. Khi nhìn hệ thống từ nhiều hướng nhìn khác nhau, tại một thời điểm có thể người ta chỉ tập trung vào một khía cạnh của hệ thống. Một biểu đồ chứa các kí hiệu hình học mô tả các phần tử mô hình của hệ thống. UML có tất cả các hướng nhìn sau:

- Hướng nhìn Use case (use case view) : đây là hướng nhìn chỉ ra khía cạnh chức năng của một hệ thống, nhìn từ hướng tác nhân bên ngoài.

- Hướng nhìn logic (logical view): chỉ ra chức năng sẽ được thiết kế bên trong hệ thống như thế nào, qua các khái niệm về cấu trúc tĩnh cũng như ứng xử động của hệ thống.

- Hướng nhìn thành phần (component view): chỉ ra khía cạnh tổ chức của các thành phần code.

- Hướng nhìn song song (concurrency view): chỉ ra sự tồn tại song song/ trùng hợp trong hệ thống, hướng đến vấn đề giao tiếp và đồng bộ hóa trong hệ thống.

- Hướng nhìn triển khai (deployment view): chỉ ra khía cạnh triển khai hệ thống vào các kiến trúc vật lý (các máy tính hay trang thiết bị được coi là trạm công tác).

II.3.2. Biểu đồ (diagram)

Biểu đồ là các hình vẽ bao gồm các ký hiệu phần tử mô hình hóa được sắp xếp để minh họa một thành phần cụ thể hay một khía cạnh cụ thể của hệ thống. Một mô hình hệ thống thường có nhiều loại biểu đồ, mỗi loại có nhiều biểu đồ khác nhau.

Biểu đồ Use case (Use Case Diagram):

Một biểu đồ Use case chỉ ra một số lượng các tác nhân ngoại cảnh và mối liên kết của chúng đối với Use case mà hệ thống cung cấp. Một Use case là một lời miêu tả của một chức năng mà hệ thống cung cấp. Lời miêu tả Use case thường là một văn bản tài liệu, nhưng kèm theo đó cũng có thể là một biểu đồ hoạt động. Các Use case được miêu tả duy nhất theo hướng nhìn từ ngoài vào của các tác nhân (hành vi của hệ thống theo như sự mong đợi của người sử dụng), không miêu tả chức năng được cung cấp sẽ hoạt động nội bộ bên trong hệ thống ra sao. Các Use case định nghĩa các yêu cầu về mặt chức năng đối với hệ thống.

Biểu đồ use case của một công ty bảo hiểm

Biểu đồ lớp (Class Diagram):

Một biểu đồ lớp chỉ ra cấu trúc tĩnh của các lớp trong hệ thống. Các lớp là đại diện cho các “vật” được xử lý trong hệ thống. Các lớp có thể quan hệ với nhau trong nhiều dạng thức: liên kết (associated - được nối kết với nhau), phụ thuộc (dependent - một lớp này phụ thuộc vào lớp khác), chuyên biệt hóa (specialized - một lớp này là một kết quả chuyên biệt hóa của lớp khác), hay đóng gói ( packaged - hợp với nhau thành một đơn vị). Tất cả các mối quan hệ đó đều được thể hiện trong biểu đồ lớp, đi kèm với cấu trúc bên trong của các lớp theo khái niệm thuộc tính (attribute) và thủ tục (operation).

Biểu đồ lớp cho một giao dịch Tài chính

 Biểu đồ đối tượng (Object Diagram):

Một biểu đồ đối tượng là một phiên bản của biểu đồ lớp và thường cũng sử dụng các ký hiệu như biểu đồ lớp. Sự khác biệt giữa hai loại biểu đồ này nằm ở chỗ biểu đồ đối tượng chỉ ra một loạt các đối tượng thực thể của lớp, thay vì các lớp. Một biểu đồ đối tượng vì vậy là một ví dụ của biểu đồ lớp, chỉ ra một bức tranh thực tế có thể xảy ra khi hệ thống thực thi: bức tranh mà hệ thống có thể có tại một thời điểm nào đó.

Biểu đồ lớp và biểu đồ đối tượng thể hiện của lớp

Biểu đồ trạng thái (State Diagram):

Một biểu đồ trạng thái thường là một sự bổ sung cho lời miêu tả một lớp. Nó chỉ ra tất cả các trạng thái mà đối tượng của lớp này có thể có, và những sự kiện (event) nào sẽ gây ra sự thay đổi trạng thái. Một sự kiện có thể xảy ra khi một đối tượng tự gửi thông điệp đến cho nó - ví dụ như để thông báo rằng một khoảng thời gian được xác định đã qua đi – hay là một số điều kiện nào đó đã được thỏa mãn. Biểu đồ trạng thái không được vẽ cho tất cả các lớp, mà chỉ riêng cho những lớp có một số lượng các trạng thái được định nghĩa rõ ràng và hành vi của lớp bị ảnh hưởng và thay đổi qua các trạng thái khác nhau.

Một ví dụ về biểu đồ trạng thái

Biểu đồ trình tự (Sequence Diagram):

Một biểu đồ trình tự chỉ ra một cộng tác động giữa một loạt các đối tượng. Khía cạnh quan trọng của biểu đồ này là chỉ ra trình tự các thông điệp (message) được gửi giữa các đối tượng. Nó cũng chỉ ra trình tự tương tác giữa các đối tượng, điều sẽ xảy ra tại một thời điểm cụ thể nào đó trong trình tự thực thi của hệ thống. Các biểu đồ trình tự chứa một loạt các đối tượng được biểu diễn bằng các đường thẳng đứng. Trục thời gian có hướng từ trên xuống dưới trong biểu đồ, và biểu đồ chỉ ra sự trao đổi thông điệp giữa các đối tượng khi thời gian trôi qua. Các thông điệp được biểu diễn bằng các đường gạch ngang gắn liền với mũi tên (biểu thị thông điệp) nối liền giữa những đường thẳng đứng thể hiện đối tượng. Trục thời gian cùng những lời nhận xét khác thường sẽ được đưa vào phần lề của biểu đồ.

Một biểu đồ trình tự cho Print Server

Biểu đồ cộng tác (Collaboration Diagram):

Một biểu đồ cộng tác chỉ ra một sự cộng tác động, cũng giống như một biểu đồ trình tự. Thường người ta sẽ chọn hoặc dùng biểu đồ trình tự hoặc dùng biểu đồ cộng tác. Bên cạnh việc thể hiện sự trao đổi thông điệp (được gọi là tương tác), biểu đồ cộng tác chỉ ra các đối tượng và quan hệ của chúng (nhiều khi được gọi là ngữ cảnh).

Biểu đồ cộng tác về quản lý học viên

II.3.3. Phần tử mô hình (Model element)

Các khái niệm được sử dụng trong các biểu đồ được gọi là các phần tử mô hình (model element). Một phần tử mô hình được định nghĩa với ngữ nghĩa (semantic), đó là một định nghĩa về bản chất phần tử hay là một xác định ý nghĩa chính xác xem nó sẽ thể hiện điều gì trong những lời khẳng định rõ ràng. Mỗi phần tử mô hình còn có một sự miêu tả trực quan, một ký hiệu hình học được sử dụng để miêu tả phần tử này trong biểu đồ.

Một vài loại quan hệ đáng chú ý:

-         Nối kết (Association) : nối các phần tử và các thực thể nối (link).

-         Khái quát hóa (Generalization): còn được gọi là tính thừa kế, có ý nghĩa rằng một phần tử này có thể là một sự chuyên biệt hóa của một phần tử khác.

-         Sự phụ thuộc (Dependency): chỉ ra rằng một phần tử này phụ thuộc trong một phương thức nào đó vào một phần tử khác.

-         Kết tập (Aggregation): Một dạng của nối kết, trong đó một phần tử này chứa các phần tử khác.

Ngoài ra còn có các phần tử mô hình khác như thông điệp (Message), hành động (action) và khuôn mẫu (stereotype).

II.3.4. Cơ chế chung (general mechanism)

UML thể hiện một số các cơ chế chung trong tất cả các biểu đồ nhằm mục đích cung cấp thêm các thông tin bổ sung, thường đây là những thông tin không thể được thể hiện qua các chức năng và khả năng cơ bản của các phần tử mô hình.

- Trang trí (Adornment): Các sự trang trí trực quan có thể được sử dụng kèm thêm vào các phần tử mô hình trong biểu đồ. Động tác trang trí bổ sung thêm ngữ nghĩa cho phần tử.

- Ghi chú (Note): Nhằm tạo điều kiện bổ sung thêm cho một mô hình những thông tin không thể được thể hiện bằng phần tử mô hình, UML cung cấp khả năng kèm theo lời ghi chú. Một lời ghi chú có thể được để bất kỳ nơi nào trong bất kỳ biểu đồ nào, và nó có thể chứa bất kỳ loại thông tin nào. Dạng thông tin của bản thân nó là chuỗi ký tự (string), không được UML diễn giải.

- Đặc tả (Specification): Các phần tử mô hình có thuộc tính (Property) chứa các giá trị dữ liệu về phần tử này. Một thuộc tính được định nghĩa với một tên và một giá trị đính kèm (tagged value), thường chúng ở trong một dạng thông tin được xác định trước, ví dụ như số nguyên hay chuỗi kí tự. Thuộc tính được sử dụng để thêm các đặc tả bổ sung về một phần tử, những thông tin bình thường ra không được thể hiện trong biểu đồ.