Phân tích thiết kế hệ thống thông tin

PHÂN TÍCH THIẾT KẾ HỆ THỐNG
Tiếp cận hướng đối tượng
Tháng 9-2007
ThS. Nguyễn Anh Hào
Khái niệm tiếp cận hướng đối tượng
Tiếp cận hướng Process (diễn tả vấn đề thành các chức năng), hay Entity Relationship (diễn tả vấn đề bằng thực thể và các quan hệ) có 2 đặc điểm chung:
Các thực thể được mô hình hóa từ một khía cạnh (chức năng hoặc dữ liệu), không thể diễn tả trọn vẹn một thực thể trong thế giới thực.
Các thực thể được mô tả tách biệt với môi trường mà chúng hoạt động (môi trường vận hành của hệ thống).
Trong cách tiếp cập hướng đối tượng, mỗi thực thể được xem là nó đang “sống”; nó có thể phát triển tương đối độc lập trong hệ thống mà không làm phá vỡ hệ thống.
Quan điểm này là nền tảng để phát triển hệ thống một cách mềm dẻo.
Khái niệm tiếp cận hướng đối tượng
Bản chất của phân tích hướng đối tượng (Object Oriented Analysis) và thiết kế hướng đối tượng (Object Oriented Design) là nó quan tâm tìm hiểu vấn đề từ góc nhìn của các đối tượng, sự vật có trong vấn đề.
OO là cách suy nghĩ trừu tượng về một vấn đề thông qua các khái niệm trong thế giới thực (chứ không phải bằng các khái niệm thuần tuý máy tính): Ý niệm về thế giới thực được mô hình hóa thành các lớp đối tượng (classes) gắn kèm với trạng thái (state), hành vi (behavior) và sự cộng tác (collaboration) của các đối tượng trong lớp, để nhằm diễn giải cho một hệ thống đang tồn tại và phát triển.
Mô hình hóa trong OO
Mô hình hóa hệ thống trong OOAD dựa trên 8 nguyên lý:
Phân lớp đối tượng (Classification)
Đóng gói (Encapsulation)
Tổng quát hóa & chuyên biệt hóa (Gen./Spec./In.)
Đa hình hóa (Polymorphism)
Kết tập (Aggregation, Composition)
Kết hợp (Association)
Hợp tác (Collaboration)
Truyền thông điệp (message passing)
1. Phân lớp đối tượng
Nhóm các thực thể (đối tượng) cùng chung một số đặc tính, vào trong một lớp = Lớp đối tượng.
Đối tượng (Object)
Đối tượng: là một thực thể có một vai trò được định nghĩa rõ trong ngữ cảnh áp dụng, có trạng thái (state), hành vi (behavior) và định danh. Một đối tượng có thể quan sát được (con người, nơi), hoặc chỉ là 1 ý niệm (phòng ban, tình trạng hôn nhân, đăng ký).
Trạng thái: bao gồm tài sản của đối tượng (các thuộc tính và các quan hệ) và giá trị của thuộc tính & quan hệ.
Hành vi: diễn tả 1 đối tượng hành động hoặc phản ứng như thế nào trong môi trường.
Class
Object
2. Đóng gói (Encapsulation)
Là cơ chế gắn kết thuộc tính của đối tượng (properties) với các hành vi của đối tượng (methods) vào trong một thể thống nhất; bao bọc cho cả hai được an toàn đối với các tác động từ bên ngoài (để bảo vệ / che giấu thông tin riêng).
Methods sử dụng được từ bên ngoài = ‘services’
3. Tổng quát hóa/Chuyên biệt hóa
Là cơ chế diễn tả sự tương tự nhau giữa các lớp, thể hiện ở các thuộc tính và các dịch vụ giống nhau giữa các lớp trong cấu trúc phân lớp. Sự giống nhau đó được gọi là Inheritance
4. Đa hình hóa (Polymorphism)
Là cơ chế cho phép đa ngữ nghĩa trong cách sử dụng các dịch vụ của đối tượng; tuy tên gọi cho các dịch vụ rất giống nhau (‘move()’) ở các đối tượng (‘circle’, ‘polygon’, ‘line’), nhưng cách thực hiện các dịch vụ này lại khác nhau.
5. Kết tập (Aggregation)
Xem một tập các đối tượng như là một đối tượng duy nhất.
1 xe hơi bao gồm các bánh xe (tyres) và động cơ (engine).
1 đơn đặt hàng gồm thông tin khách hàng (cust-info) và các mặt hàng được yêu cầu (items).
6. Kết hợp (Association)
Là mối quan hệ “logic” giữa các đối tượng (giống như quan hệ trong ERD).
7. Hợp tác (Collaboration)
Là sự liên kết dịch vụ giữa các đối tượng, qua cơ chế truyền thông điệp. Nó mô tả sự tương tác giữa các đối tượng để thực hiện một vài hành vi theo một kịch bản nào đó.
User là khách hàng muốn cập nhật dữ liệu của họ vào hệ thống:
8. Truyền thông điệp (Message passing)
Là cơ chế gửi thông điệp mang yêu cầu từ một đối tượng (Client) đến một đối tượng khác (Agent) để nhờ thực hiện. Đây là cơ chế thực hiện theo nghĩa hợp tác, chứ không phải theo mệnh lệnh:
Việc thông dịch message phụ thuộc ở Agent, và
Agent có thể ủy thác (delegate) cho một Agent khác thực hiện.
Sự ủy thác (Delegation): Thông điệp mang yêu cầu được chuyển đi từ đối tượng này đến đối tượng khác cho đến khi có một đối tượng đáp ứng được yêu cầu.
Công việc từ Giám đốc chuyển đến Trưởng phòng, Trưởng phòng ủy thác cho chuyên viên thực hiện.
Tiếp cận hướng đối tượng
Trình tự thực hiện gồm:
Xác định các use cases
Thiết lập các (lớp) đối tượng
Thiết lập quan hệ giữa các lớp
Mô hình hóa hệ thống bằng UML
Lược đồ tuần tự
Lược đồ cộng tác
Lược đồ trạng thái
Lược đồ hoạt động
Phân tích, thiết kế: là quá trình gở bỏ hoặc bổ sung dần các thuộc tính, đối tượng và lớp đối tượng trong lược đồ UML cho phù hợp với giải pháp.
Use case
Một goal (mục đích) của hệ thống là một giá trị kinh tế (ích lợi) đối với users có tương tác với hệ thống đó (hoặc có giá trị kinh tế đối với hệ thống lớn hơn).
Một actor (tác nhân) là một đối tượng bên ngoài hệ thống có tương tác với hệ thống.
Một use case là một mô tả cho một trường hợp tương tác nhằm thực hiện một goal của một (hoặc một nhóm) actor.
Nó đặc tả một chuổi hành động (ie, chức năng) mà hệ thống thực hiện để tạo ra giá trị sử dụng
Nó đặc tả một chuổi các tương tác (ie, kịch bản) giữa hệ thống với một hoặc nhiều actors.
Use case
Nhìn theo quan điểm của users (actors), hệ thống là một tập họp các use cases, mỗi use case liên kết với một chức năng do hệ thống cung cấp. Một use case diễn tả một dịch vụ được cung cấp từ một (hoặc một số) đối tượng trong hệ thống.
Account management system
Use case
Quan hệ tổng quát hóa/chuyên biệt hóa: Use case A là một sự tổng quát hóa của use case B nếu use case B là một thể hiện chuyên biệt hóa của use case A.
Manage Account
Open Account
Close Account
Adjust Error
A
B
Use case
Quan hệ <>:Use case B ‘include’ use case A nếu use case B sử dụng chung use case A (A phải có cho B).
Quan hệ <>: Use case A ‘extend’ use case C nếu C là một trường hợp mở rộng xử lý của A (A có thể cần C, có thể không)
Use case
Tổng quát hóa/chuyên biệt hóa cho actor: Nếu Actor A là một sự tổng quát hóa của actor B và C thì những gì actor A thực hiện được trên hệ thống, các actor B và C cũng làm được.
Thiết lập use cases
Actors và vai trò trên hệ thống (use cases), có thể là
Users của hệ thống
Ứng dụng bên ngoài hệ thống
Thiết bị bên ngoài có tương tác với hệ thống
Sự kiện kích hoạt hệ thống theo thời gian
Quan hệ giữa các use cases (include/extend/gen./spec.)
Điều kiện để use case được kích hoạt
Kết quả mong đợi từ use case
Các ngoại lệ (vd: từ chối thực hiện do lổi)
Các ràng buộc (vd: miền giá trị hợp lệ, timeout,..)
Sự tùy biến trên các use cases
Lược đồ use case
Manage Account
Open Account
Close Account
Adjust Error
Monitor Account
Lược đồ use case cho hệ thống quản lý tài khoản ngân hàng
Liên kết use case với lược đồ tuần tự
Bank Manager
system
Open account
Request customer data
Provide customer data
Reqquest account type
Provide account type
Request intial balance
Provide initial balance
Confirmation
Lược đồ tuần tự cho “open account” use case
Messages
Trình tự tương tác
Liên kết use case với lược đồ cộng tác
Lược đồ cộng tác cho “open account use case”
:CustManager
1: OpenAccount()
2: ReqCustInfo()
3: CustomerInfo(data)
5: ReqAccountType()
6: AccountType(Acctype)
7: ReqIntialBalance()
8: InitialBalance(InitBalance)
10: Confirmation()
:AccManager
4: Activate()
:AccDatabase
9: CreateAcc()
Phương pháp tìm các đối tượng
Sử dụng vật thể (các khái niệm vật chất quen thuộc)
Xác định các vật thể, như con người, vật dụng, tổ chức (truờng học, bệnh viện, công ty,…), vị trí địa lý, bản báo cáo,… trong phạm vi của vấn đề đang khảo sát
Xác định các đối tượng và lớp đối tượng tương ứng với vật thể
Sử dụng cách phân rã đối tượng
Tìm kết tập hoặc lớp đối tượng
Phân rã (chuyên biệt hóa) thành các đối tượng thành phần
Sử dụng cách tổng quát hóa đối tượng
Xác định các đối tượng hoặc lớp đối tượng trong vấn đề
Tìm các đối tượng có những thuộc tính và dịch vụ tương tự nhau để tổng quát hóa thành lớp đối tượng trừu tượng mà các đối tượng đã biết có thể kế thừa được

Xác định thuộc tính của đối tượng
Thuộc tính: Dữ liệu gì làm đối tượng có thể nhận biết được trong môi trường hoặc sở hữu như tài sản riêng.
Đối tượng được mô tả tổng quát như thế nào ?
Phần nào trong mô tả là hữu ích cho bài toán ?
Vậy đặc tả tối thiểu cho đối tượng trong phạm vi bài toán đang giải quyết là gì ?
Các loại thuộc tính:
Thuộc tính mô tả: là các facts của đối tượng được nhìn từ bên ngoài (môi trường). Vd: Jan nặng thêm 1 kg.
Thuộc tính định danh: là các thuộc tính để phân biệt đối tượng; một đối tượng có nhiều tên gọi và khi tên gọi thay đổi, đối tượng vẫn tồn tại như trước

Xác định thuộc tính của đối tượng
Thuộc tính của đối tượng phải phù hợp với ý nghĩa của đối tượng trong ngữ cảnh mà đối tượng đang tồn tại. Vd: năm kinh nghiệm và tuổi của một lập trình viên.
Có giá trị ở mọi thời điểm.
Không chứa cấu trúc bên trong.
Là đặc tính của cả thực thể chứ không chỉ của thành phần trong thực thể. VD: Computer gồm CPU, bàn phím, màn hình, con chuột. Kích thước màn hình là thuộc tính của màn hình, không phải của computer.
Nếu 1 đối tượng trừu tượng có tương tác với đối tượng khác, thuộc tính của nó phải thể hiện ý nghĩa của chính nó. Vd: mô hình hóa đối tượng bơm xăng: số lít được bơm ≠ lượng xăng trong bình chứa, hoặc dung tích của máy bơm.
Xác định dịch vụ của đối tượng
Dịch vụ: là công việc cần thực hiện cho đối tượng khác, được kích hoạt qua cơ chế truyền thông điệp và được định nghĩa qua giao tiếp, gồm:
Tên gọi của dịch vụ
Thông số: là những gì đối tượng cần (nhưng chưa có sẵn) để thực hiện dịch vụ
Giá trị trả về là giá trị cung cấp cho đối tượng khác
Ngoại lệ :những trường hợp bị từ chối thực hiện
Trong quá trình phân tích và thiết kế, chỉ có tên gọi của dịch vụ là cần phải cân nhắc kỹ về ý nghĩa của nó trong phạm vi của bài toán; còn các thông số, giá trị trả về và các ngoại lệ sẽ dần dần được tinh chỉnh tùy theo mức độ cài đặt về phương diện kỹ thuật.
Xác định hành vi của đối tượng
Hành vi: là một tập các hành động mà đối tượng cần thực hiện để cung cấp dịch vụ, được định nghĩa trên 3 yếu tố:
Đầu vào (thông số của dịch vụ)
Đầu ra (kết quả trả về)
Làm thế nào đối tượng thực hiện được dịch vụ
Hành vi tĩnh (static behavior)
Các hành vi của đối tượng không bị ảnh hưởng (không thay đổi tính chất xử lý) đối với các sự kiện kích hoạt. Vd: lấy căn bậc 2.
Hành vi tĩnh của đối tượng có thể được diễn tả bằng lược đồ hoạt động (activity diagram).
Hành vi động (dynamic behavior)
Các hành vi của đối tượng bị thay đổi tùy theo trạng thái của đối tượng tại thời điểm phát sinh sự kiện kích hoạt.Vd: trạng thái hoạt động của lò vi ba.
Hành vi động của đối tượng được diễn tả bằng lược đồ trạng thái (state diagram).
Lược đồ hoạt động (activity diagram)
Mô hình trạng thái
Một mô hình trạng thái diễn tả mối quan hệ giữa các trạng thái, các sự kiện kích hoạt đối tượng chuyển trạng thái, và chuyển trạng thái của đối tượng.
Trạng thái: là giá trị của các thuộc tính mô tả đối tượng trong từng khoảng thời gian xác định (trước hoặc sau khi phản ứng với sự kiện).
Sự kiện: là điều kiện kích hoạt hành vi của đối tượng.
Chuyển trạng thái: là sự thay đổi trạng thái của đối tượng do phản ứng với sự kiện kích hoạt.
Hành động: là hoạt động bên trong của đối tượng gây ra sự thay đổi trạng thái.
Ví dụ chuyển trạng thái của lò viba
: Oven
: Light
: Tube
: Timer
Door opened
Turn on
Door closed
Turn off
Put in food
Button pushed
Set timer for 1 minute
Turn on
Button pushed
Add 1 minute
Time out
Turn off
Turn off
Turn on
Lược đồ trạng thái (state diagram) của lò viba
Xác định quan hệ của đối tượng
Đối tượng có 3 loại quan hệ cơ bản sau
Tổng quát hóa (generalization), ví dụ: cha con.
Kết tập (aggregation, composition), ví dụ: xe hơi.
Kết hợp (association), ví dụ: hôn nhân.
Xác định các quan hệ giữa các đối tượng là để tìm ra sự hợp tác giữa các đối tượng dựa trên vai trò của chúng trong phạm vi của bài toán đang giải quyết.
Quan hệ tổng quát hóa (generalization)
Quan hệ “is_a”: nếu đối tượng A có một quan hệ is_a với đối tượng B thì tất cả các thuộc tính và dịch vụ của B đều có ở A. Ví dụ: Employee “is_a” Person.
Quan hệ tổng quát hóa là một quan hệ is_a: đối tượng B là một sự tổng quát hóa (cha) của đối tượng A (con), theo một quan điểm nào đó. Như vậy, một đối tượng có thể có nhiều cách tổng quát hóa (nhiều cha): trường hợp này là một sự đa thừa kế (multiple inheritance). Ví dụ: lập trình viên có 2 tổng quát hóa: con người, và lập trình.
Quan hệ tổng quát hóa có thể không tồn tại vĩnh cữu. Nếu 1 nhân viên không còn làm việc nữa thì anh ta không còn thừa kế các thuộc tính của đối tượng “làm công” (lĩnh lương, thăng tiến, nghỉ phép)
Quan hệ tổng quát hóa (generalization)
Các đặc tính của quan hệ tổng quát hóa
Đối tượng con thừa hưởng được toàn bộ thuộc tính, quan hệ và dịch vụ của đối tượng cha.
Đối tượng con có thể thừa hưởng trọn vẹn hành vi của đối tượng cha, và cũng có thể thay đổi các hành vi này (polymophism).
Nếu B là tổng quát hóa của A, thì A không là tổng quát hóa của B (bất đối xứng)
Nếu A “is_a” B và B “is_a” C thì A “is_a” C (bắc cầu)

UML cho quan hệ tổng quát hóa
Các đặc tính của lược đồ UML cho qh.tổng quát hóa
Disjoint: không có đối tượng nào thuộc nhiều lớp, ngược lại là Overlaping.
Complete: Subclasses được vẽ đầy đủ trên lược đồ, ngược lại là Incomplete (vẫn còn một số subclass chưa xác định).
“Disjoint, Complete”
UML cho quan hệ tổng quát hóa
“Disjoint, Incomplete”
UML cho quan hệ tổng quát hóa
“Overlaping, Complete”
Research & teaching
Assistant
“Multiple Inheritance”
Quan hệ kết tập (aggregation)
Là quan hệ diễn tả sự liên kết nhiều đối tuợng có chung một mục đích (chức năng) để “tạo thành” một đối tượng duy nhất, dựa trên một số tính chất:
Tích hợp các thành phần (component-integral).Vd: bánh xe, máy, khung … tạo thành xe.
Vật liệu làm ra vật thể. Vd: sắt, gỗ, nhựa,… làm ra ghế.
Nội dung chứa bên trong (container content).Vd: các mục hàng, ngày mua, nơi,… trong yêu cầu đặt hàng.
Giống như quan hệ tổng quát hóa, kết tập có tính bất đối xứng, bắc cầu và các đối tượng đều có một vài chức năng chung; nhưng trong kết tập không có tính kế thừa.
UML định nghĩa 2 loại kết tập: aggregation và composition.
UML cho quan hệ kết tập
Aggregation
Composition
UML cho quan hệ kết hợp (association)
Ví dụ:
UML cho quan hệ kết hợp
Customer Order của nhà hàng Hoosie Burger
Customer
Places
Includes
Requests
*
*
Order
Product
Product Line
1
1..*
1
1..*
Course
Teaches
Register for
0..10
*
Student
CourseOffer
Faculty
0..1
*
1,2
*
Scheduled for
*
1
Advisor
Advisee
Tổ chức dạy học ở trường đại học