Tải bản đầy đủ (.pdf) (43 trang)

Bài giảng phân tích và thiết kế hướng đối tượng bài giảng 1 TS đào nam anh

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (2.22 MB, 43 trang )

PHÂN TÍCH VÀ THIẾT KẾ HƯỚNG ĐỐI TƯỢNG
OBJECT ORIENTED ANALYSIS AND DESIGN
DR. DAO NAM ANH
Bài giảng 1:
Phương pháp hướng đối tượng và

quá trình phát triển hệ thống phần mềm

1


RESOURCE - REFERENCE

1.
2.

3.
4.
5.
6.

Ian Sommerville, Software Engineering, Ninth Edition, 2011
Bernd Bruegge & Allen H. Dutoit. Object-Oriented
Software Engineering: Using UML, Patterns, and Java,
Third Edition, Prentice Hall, 2010
Russell C. Bjork, ATM Simulation Links, Gordon College
Hans-Erik Eriksson, Magnus Penker, Brian Lyons, David
Fado, UML 2 Toolkit, John Wiley & Sons Inc, 2003
Dương Kiều Hoa – Tôn Thất Hoà An, Phân tích và thiết kế
Hệ thống thông tin với UML, 2006
Đào Nam Anh, Giáo Trình Phân Tích Và Thiết Kế Hướng


Đối Tượng, Đại học Điện lực, 2013
2


CONTENT – NỘI DUNG
Phương pháp hướng đối tượng và quá trình phát
triển hệ thống phần mềm
1. Giới thiệu về hệ thống phần mềm
2. Sự phát triển hệ thống
3. Các cách tiếp cận trong phát triển phần mềm
4. Quá trình phát triển phần mềm hợp nhất
3


Công nghệ phần mềm
1.

2.

3.

4.

Công việc lập mô hình (modeling)
Giải quyết sự phức tạp thông qua các mô hình, bằng cách
tập trung vào các chi tiết có liên quan tại một thời điểm và
bỏ qua tất cả chi tiết khác.
Việc giải quyết vấn đề (problem-solving)
Các mô hình được sử dụng để tìm ra một giải pháp có thể
chấp nhận được.

Việc thu thập kiến thức (knowledge acquisition)
Trong khi lập mô hình cho các ứng dụng và lĩnh vực liên
quan, kỹ sư phần mềm thu thập dữ liệu, tổ chức thành thông
tin, và tổng hợp thành kiến thức.
Hoạt động hướng hợp lý (rationale-driven)
Khi thu thập kiến ​thức và đưa ra các quyết định về hệ thống,
kỹ sư phần mềm cũng cần phải hiểu bối cảnh thực hiện các
quyết định, lý do đằng sau những quyết định này.

4


Lập mô hình






Mô hình là kết quả của sự trừu tượng, nhằm miêu tả
các thành phần cốt yếu của một vấn đề hay một cấu trúc
phức tạp, qua việc lọc bớt các chi tiết không quan trọng
và làm cho vấn đề dễ hiểu hơn.
Lập mô hình rất có ích với các hệ thống quá lớn, phức
tạp, hoặc quá đắt để có thể trực tiếp trải nghiệm. Lập mô
hình cũng cho phép ta hình dung và hiểu hệ thống, cho
dù nó không còn tồn tại hoặc mới chỉ là ý tưởng.
Trong dự án có các khách hàng, chuyên gia của lĩnh vực
liên quan, phân tích viên, người thiết kế. Mô hình hoá
giúp mọi người trong dự án trao đổi, hiểu hệ thống. Các

mô hình giúp hiểu các yêu cầu của hệ thống tốt hơn, tạo
các thiết kế rõ ràng hơn và xây dựng các hệ thống có khả
năng dễ bảo trì hơn.

5


Mô hình lĩnh vực ứng dụng
Mô tả những khía cạnh của hệ thống thực tế
có liên quan đến các vấn đề đang được xem
xét.
 Kỹ sư phần mềm cần phải hiểu môi trường
trong đó hệ thống hoạt động.
 Với hệ thống điều khiển giao thông đường
sắt, kỹ sư phần mềm cần biết các thủ tục báo
hiệu tàu.
 Với hệ thống giao dịch ngân hàng, kỹ sư
phần mềm cần phải biết các quy tắc giao
dịch ngân hàng.


6


Mô hình lĩnh vực các giải pháp
Kỹ sư phần mềm cần phải hiểu những hệ
thống họ sẽ xây dựng, để đánh giá được
các giải pháp khác nhau và lựa chọn giải
pháp.
 Hầu hết các hệ thống quá phức tạp để có

thể hiểu được hết, và hầu hết các hệ thống
quá đắt để xây dựng.
 Với những thách thức này, kỹ sư phần
mềm tìm hiểu và mô tả các khía cạnh
quan trọng của những hệ thống thay thế.


7


Phương pháp hướng đối tượng kết
hợp việc mô hình
Lĩnh vực ứng dụng được mô hình hóa
bằng một tập các đối tượng và các liên
kết. Sau đó sử dụng mô hình này để mô tả
các hoạt động của hệ thống.
 Lĩnh vực giải pháp cũng được mô hình
hóa bằng các đối tượng.


8


Giải quyết vấn đề
Công nghệ chính là một hoạt động giải
quyết vấn đề (problem solving)
1. Phát biểu vấn đề,
2. Phân tích vấn đề,
3. Tìm kiếm các giải pháp,
4. Quyết định giải pháp thích hợp,

5. Đặc tả giải pháp.

9


Giải quyết vấn đề
Phát triển phần mềm hướng đối tượng
thường có 6 hoạt động:
1. Lấy yêu cầu,
2. Phân tích,
3. Thiết kế hệ thống,
4. Thiết kế đối tượng,
5. Lập trình, và
6. Kiểm thử.


10


Thu thập Kiến thức
Sai lầm phổ biến khi cho rằng việc thu
thập kiến thức (knowledge acquisition) là
một tiến trình tuần tự. Thực tế đó là một
tiến trình không tuần tự.
 Việc bổ sung một đoạn mới của thông tin
có thể làm mất hiệu lực tất cả các
kiến ​thức đã có từ trước.


11



Thu thập Kiến thức

Tránh sự tuần tự của mô hình thác nước
 Mô hình phát triển dựa trên rủi ro (riskbased development)
 Mô hình phát triển dựa trên sự cố (issuebased development)


12


Sự hợp lý
Phát triển phần mềm hay gặp các hệ thống
thay đổi liên tục. Thay đổi hệ thống có thể
là việc khách hàng áp dụng thêm công
nghệ mới.
 Việc bổ sung kiến ​thức này được gọi là sự
hợp lý (rationale) của hệ thống.


13


Sự phát triển hệ thống
Trong quá trình phát triển hệ thống có sự
tham gia của nhiều người với các vai trò
khác nhau.
 Quá trình phát triển được diễn ra trong
một chu kỳ.



14


Vai trò
Chu trình phát triển phần mềm (Software
Development Life Cycle - SDLC) cần sự
cộng tác của nhiều người với các nhiệm
vụ và lợi ích khác nhau: nhà phân tích
(Analyst), thiết kế viên (Designer), người
phát triển (Developer) và người dùng
(User).
 Những người tham gia vào dự án như vậy
được xếp vào các vai trò (role) để thể hiện
các nhiệm vụ của mình trong dự án.


15


Vai trò
Nhà phân tích (Analyst)
 Thiết kế viên (Designer)
 Nhà phân tích (Analyst)
 Thiết kế viên (Designer)
 Người dùng (User)


16



Giai đoạn của Chu trình phát
triển phần mềm
Tập hợp yêu cầu (Requirement capture)
 Phân tích yêu cầu (Analysis)
 Thiết kế hệ thống (System design)
 Thiết kế đối tượng (Object design)
 Thực hiện, triển khai (Implementation)
 Kiểm thử (Testing)


17


Giai đoạn của Chu trình phát
triển phần mềm
Tập hợp yêu cầu
 Khách hàng và các nhà phát triển xác định mục
đích của hệ thống.
 Kết quả của hoạt động này là tài liệu mô tả của hệ
thống về các tác nhân (actor) và các Use Case.
 Tác nhân đại diện cho các thực thể bên ngoài
tương tác với hệ thống. Tác nhân bao gồm vai trò
người dùng cuối, các máy tính khác mà hệ thống
cần phải kết nối, và môi trường tương tác.
 Use Case mô tả trình tự các các hành động có thể
xảy ra giữa tác nhân và hệ thống cho một nhóm
các chức năng.
18



Giai đoạn của Chu trình phát
triển phần mềm
Phân tích hệ thống
 Xây dựng một mô hình của hệ thống chính xác, đầy
đủ, phù hợp, và rõ ràng.
 Các thiết kế viên chuyển đổi các Use Case có được từ
bước tập hợp yêu cầu, thành một mô hình các đối
tượng (object model) mô tả toàn bộ hệ thống.
 Thiết kế viên có thể phát hiện ra một số điều không rõ
ràng và thiếu nhất quán ở các Use Case, họ sẽ thảo
luận với khách hàng để làm rõ.
 Kết quả việc phân tích là một mô hình hệ thống
(system model) với các diễn giải các thuộc tính, hoạt
động, và các liên kết.
19


Giai đoạn của Chu trình phát
triển phần mềm
Thiết kế hệ thống
 Xác định các mục tiêu thiết kế của dự án và phân
rã hệ thống vào các hệ thống con nhỏ.
 Lựa chọn chiến lược để xây dựng hệ thống, chẳng
hạn như xác định môi trường của hệ thống về
phần cứng / phần mềm, chiến lược quản lý dữ
liệu, kiểm soát luồng thông tin, chính sách kiểm
soát truy cập, và xử lý các điều kiện biên.
 Kết quả của việc thiết kế hệ thống là một mô tả rõ

ràng của từng chiến lược này, hệ thống phân rã, và
biểu đồ triển khai thể hiện quan hệ phần cứng /
phần mềm của hệ thống.
20


Giai đoạn của Chu trình phát
triển phần mềm
Thiết kế đối tượng
 Thiết kế viên xác định các đối tượng trong lĩnh
vực giải pháp.
 Bước này khai báo các đối tượng, giao diện giữa
các hệ thống con, cơ cấu lại mô hình đối tượng để
đạt các mục tiêu thiết kế như khả năng mở rộng hệ
thống hoặc dễ hiểu, và tối ưu hóa mô hình đối
tượng để tăng tốc độ thực hiện.
 Kết quả của các bước này là một mô hình đối
tượng chi tiết với mô tả chính xác cho từng phần
tử.
21


Giai đoạn của Chu trình phát
triển phần mềm
Xây dựng
 Trong quá trình triển khai lập trình, lập
trình viên viết mã theo mô hình lĩnh vực
giải pháp.
 Lập trình viên cũng có trách nhiệm viết tài
liệu liên quan đến chương trình, chú giải

các thủ tục (procedure) trong chương
trình.
22


Giai đoạn của Chu trình phát
triển phần mềm
Kiểm thử
 Để đảm bảo chương trình được viết phải thoả mãn mọi yêu
cầu đã nêu trong các tài liệu thiết kế.
 Người kiểm thử tìm thấy sự khác biệt giữa hệ thống và mô
hình thiết kế của nó bằng cách chạy hệ thống với các bộ dữ
liệu đầu vào.
 Kiểm thử đơn vị (unit test), lập trình viên đối chiếu chương
trình với từng đối tượng và hệ thống con trong mô hình thiết
kế đối tượng.
 Kiểm thử kết nối (integration test), các hệ thống con được
tích hợp với nhau và so sánh với các mô hình thiết kế hệ
thống.
 Kiểm thử hệ thống (system testing), các trường hợp điển hình
và ngoại lệ được chạy qua hệ thống và so sánh với mô hình
yêu cầu.
23


Các cách tiếp cận trong phát triển
phần mềm
Có nhiều chiến lược và kỹ thuật để phát
triển phần mềm:
 Phát triển hướng chức năng,

 Kỹ nghệ thông tin,
 Tạo mẫu và
 Phát triển hướng đối tượng.
Những chiến lược này có thể được kết hợp,
bổ sung cho nhau trong thực tế.
24


Các cách tiếp cận trong phát triển
phần mềm
Phát triển phần mềm hướng chức năng
 Là một trong những phương pháp chính
được áp dụng rộng rãi cho các hệ thống
thông tin và các ứng dụng máy tính.
 Đó là phương pháp lấy QUI TRÌNH làm
trung tâm, được sử dụng để mô hình các
yêu cầu nghiệp vụ cho một hệ thống

25


×