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

Bài giảng chương 7 chuyển từ giai đoạn phân tích sang giai đoạn thiết kế

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 (1.7 MB, 33 trang )

Chuyển từ giai đoạn phân tích sang giai đoan thiết kế

1


Giới thiệu
- Mục đích của q trình phân tích là tìm ra những yêu cầu về mặt nghiệp vụ của hệ
thống là gì. Mục đích của q trình thiết kế là xây dựng hệ thống như thế nào.
- Các bước thực hiện trong hai giai đoạn phân tích và thiết kế có mối quan hệ mật
thiết và chuyển đổi qua lại.

2


Mục tiêu của chương
- Hiểu được quá trình kiểm duyệt các mơ hình phân tích.
- Hiểu được sự chuyển đổi từ phân tích sang thiết kế.
- Hiểu được các kĩ thuật sử dụng trong quá trình thiết kế phân tách (factoring), phân
chia (partition) và phân tầng (layer) trong thiết kế.
- Có thể tạo các biểu đồ gói.
- Biết được các cách cách khác nhau để thiết kế hệ thống: doanh nghiệp tự xây dựng
phần mềm, mua các gói phần mềm có sẵn, th cơng ty khác xây phần mềm.
- Có thể tạo được ma trận lựa chọn.

3


Kiểm duyệt các mơ hình phân tích

4



Cuộc họp tổng duyệt các mơ hình phân tích
- Cuộc họm nhằm đánh giá của các mơ hình và sơ đồ được tạo ra trong q
trình phân tích.
- Cuộc họp được thực hiện các yhanhf viên đội phân tích và thiết kế cùng những
ngươig sử dụng.
- Mục đích chính của cuộc họp:
- Kiểm tra độ trung thực của các mô hình
- Phát hiện ra các lỗi
- Cuộc họp tiềm ẩn nguy cơ các nhà phân tích bị trách phạt nếu các mơ hình
phân tích có sai sót và bị phát hiện

5


Qui tắc xét duyệt các mơ hình chức năng
1. Các sự kiện trong mô tả ca sử dụng nên được ánh xạ với các hoạt động
trong biểu đồ hoạt động.
2. Nút đối tượng trong biểu đồ hoạt động phải được đề cập trong mô tả ca sử
dụng.
3. Trật tự tuần tự trong mô tả ca sử dụng phải khớp với thứ tự trong biểu đồ
hoạt động.
4. Phải có sự tương ứng một-một giữa các ca sử dụng trong sơ đồ ca sử dụng
với mô tả ca sử dụng.

6


Qui tắc xét duyệt các mơ hình chức năng
5. Tất cả các tác nhân liệt kê trong mô tả ca sử dụng phải được mô tả trong sơ

đồ ca sử dụng.
6. Những người liên quan được liệt kê trong mô tả ca sử dụng cũng được đưa
vào trong sơ đồ ca sử dụng như các tác nhân.
7. Tất cả các mối quan hệ được liệt kê trong mô tả ca sử dụng phải được
miêu tả trên một sơ đồ ca sử dụng.

7


Qui tắc xét duyệt mơ hình cấu trúc:
1. Mỗi thẻ CRC nên tương ứng với một lớp trên sơ đồ lớp.
2. Các nhiệm vụ được liệt kê trên thẻ CRC phải là các thao tác của lớp học
trong sơ đồ lớp.
3. Các lớp cộng trên thẻ CRC thường ngụ ý một số loại quan hệ trên sơ đồ lớp.
4. Các thuộc tính được liệt kê trên thẻ CRC phải là các thuộc tính trong của
lớp trong sơ đồ lớp

8


Qui tắc xét duyệt mơ hình cấu trúc:
5. Các thuộc tính của lớp có kiểu là một lớp khác (thuộc tính đối tượng) thường
ngụ ý là một quan hệ giữa hai lớp.
6. Các quan hệ trên thẻ CRC phải được hiển thị trên sơ đồ lớp.
7. Chỉ sử dụng các lớp kết hợp nếu như lớp nz có các thuộc tính riêng khơng
thuộc khơng nằm trong cả hai lớp tham gia quan hệ.

9



Qui tắc xét duyệt các mơ hình hành vi
1. Các tác nhân và đối tượng trong sơ đồ tuần tự phải đưa vào sơ đồ cộng tác.
2. Các thông điệp trên sơ đồ tuần tự yêu cầu phải có sự liên kết trên biểu đồ cộng
tác.
3. Mỗi thông điệp trên sơ đồ tuần tự phải xuất hiện dưới dạng một thông điệp của
liên kết trong sơ đồ cộng tác tương ứng.
4. Các điều kiện đảm bảo của thông điệp trên sơ đồ tuần tự yêu cầu các điều kiện
đảm bảo tương đương trên sơ đồ công tác.

10


Qui tắc xét duyệt các mơ hình hành vi
5. Số thứ tự của các thông điệp trong sơ đồ cộng tác phải tương ứng với số thứ tự
từ trên xuống dưới của các thông điệp gửi trong sơ đồ tuần tự.
6. Sự chuyển đổi trạng thái phải được liên kết với một thông điệp trên sơ đồ tuần
tự và sơ đồ cộng tác.
7. Tất cả các mục trong ma trận CURD ngụ ý một thông điệp được gửi từ một tác
nhân hoặc đối tượng đến một tác nhân hoặc đối tượng khác.

11


Sự cân đối giữa các mơ hình phân tích
- Sự cân bằng giữa mơ hình chức năng và mơ hình cấu trúc
- Sự cân bằng giữa mơ hình chức năng và mơ hình hành vi
- Sự cân bằng giữa mơ hình cấu trúc và mơ hình cấu trúc
(Đọc thêm các qui tắc cân đối trong sách)

12



Q trình chuyển các mơ phân tích thành các mơ hình thiết kế
- Sau quá trình kiểm duyệt và chỉnh sửa, các mơ hình phân tích được chuyển sang
thành các mơ hình thiết kế phù hợp. Trong giai đoạn phân tích, các nhà phân tích
chỉ tập trung xác định và mô tả các yêu cầu chức năng của hệ thống. Sang giai đoạn
thiết kế, ngoài việc đặc tả chi tiết thêm các yêu cầu chức năng, đội dự án quan tâm
đặc tả thêm cả các yêu cầu phi chức năng để làm sao sản phẩm phần mềm đáp
ứng được yêu cầu chức năng và dễ dàng sử dụng, bảo trì, v.v…
- Để chuyển các mơ hình phân tích thành các mơ hình thiết kế, chúng ta có thể dùng
các kĩ thuật như phân tách (factoring), phân chia dựa trên sự hợp tác (partitions
and collaborations), phân tầng kiến trúc phần mềm (layers).

13


Kỹ thuật phân tách (Factoring)
- Phân tách là quá trình tách một module thành một module khác độc lập với nó.
- Module này có thể là một lớp mới hoặc một phương thức mới.
- Lớp mới được sinh ra có quan hệ tổng quát hóa (generalization) hoặc quan hệ kết
hợp (Aggregation) với lớp mà nó vừa được tách ra từ đó.
- Kỹ thuật phân tách liên quan mật thiết với hai quá trình trừu tượng (abstraction)
và phân rã (refinement). Quá trình trừu tượng là quá trình tạo thêm một lớp cha
(superclass) từ các lớp con. Quá trình phẫn rã thì ngược lại, một lớp có thể tách
thêm thành nhiều lớp con.

14


Kỹ thuật phân chia dựa trên sự hợp tác

- Quá trình phân tách sẽ khiến hệ thống đang được thiết kế phức tạp và khó quả lý.
Khi đó, hệ thống nên được chia thành các hệ thống con. Ví dụ, hệ thống thơng tin
kế tốn có thể được chia thành các hệ thống chức năng con như hệ thống thu, hệ
thống chi, hệ thống chi trả lương.
- Trong phân tích thiết hướng đối tượng, sự phân chia được dựa trên số thông điệp
gửi qua lại giữa các đối tượng. Những đối tượng có số thơng điệp chuyển qua lại
càng nhiều thì khả năng chúng được chia vào cùng một nhóm càng cao.

15


Các tầng kiến trúc phần mềm
- Trong giai đoạn thiết kế, chúng ta mới chỉ quan tâm tới xây dưng các mơ hình mơ
tả miền bài tốn (problem domain) chứ chưa quan tâm đến môi trường của hệ
thống (system enviroment) như quản lý dữ liệu (data management), giao diện
người dùng (user interface), kiến trúc vật lý (physical architechture). Trong giai
đoạn thiết kế, chúng ta cần đưa thêm các thông tin mơi trường vào bản thiết kế.
Do đó, chúng ta sử dụng khái niệm tầng (layer) của để thực hiện việc này. Mỗi
tầng biểu diễn một thành phần của kiến trúc hệ thống phần mềm.

- Kiến trúc MVC (Model-view-controller) phân chia hệ thống phần mềm thành 3
tầng: tầng Mơ hình (Model), tầng Khung nhìn (View) và tầng điều khiển
(controller).
- Các Mơ hình là các mơ hình được dùng để biểu diễn sự logic của ứng dụng
(miền bài toán – problem domain)
- Các Khung nhìn và các Điều khiển biểu diễn sự logic của giao diện người
dùng (user interface). Các khung nhìn sử lý đầu vào và Điều khiển sử lý đầu
ra.
- Mục đích của phân tầng kiến trúc phần mềm là để tách biệt mức logic ứng dụng
với mức logic giao diện.

- Sau kiến trúc MVC của Smalltalk, nhiều kiến trúc phân tầng mở rộng khác đã được
đề xuất. Dựa trên những kiến trúc mở rộng đó, Winxom và các tác giả (nhóm tác

16


giả viết quyển sách được chọn làm tài liệu tham khảo chính của khóa học này) đã
chia kiến trúc phần mềm thành 5 tầng: tầng cơ sở (foundation), tầng miền bài toán
(problem domain), tầng quản lý dữ liệu (data management), tầng giao diện
(Human-computer interface), tầng kiến trúc vật lý (physical architecture). Mỗi tầng
chỉ chứa một số loại lớp (class) trong nó. Slide tiếp theo sẽ mơ tả sơ qua về mỗi
tầng.

16


5 tầng của một kiến trúc phần mềm:
- Tầng cơ sở: chứa các lớp cần thiết cho bất kỳ ứng dụng hướng đối tượng
nào tồn tại. Tầng này bao gồm các lớp biểu diễn các kiểu dữ liệu như integer, real,
string, list, tree, graph, set, date, time, money, v.v…
- Tầng miền bài toán: bao gồm các lớp đối tượng đã xác ddingj trong giai đoạn phân
tích. Các lớp đối tượng này sẽ được chi tiết hóa hơn ở giai đoạn thiết kế bằng
cách sử dụng các quu tắc thiết kế hướng đối tượng.
- Tầng quản lý dữ liệu: liên quan đến các đối tượng lưu trữ lâu dài trong hệ
thống. Các lớp thuộc tầng này cho phép các lớp đối tược thuộc tầng miền vấn
đề độc lập với cấu trúc lưu trữ thơng tin được sử dụng và do đó làm tăng tính
linh động trong phát triển hệ thống.
- Tầng giao diện người-máy: chứa các lớp liên quan với tầng Khung nhìn (View)
và tầng Điều khiển (Controller) trong cấu trúc MVC. Much đích của tầng này là
tách biệt sự thực thi của các giao diện người dùng với các lớp đối tượng. Điều này

cũng làm tăng tính linh động của quá trình phát triển hệ thống. Các lớp thuộc tầng
này bao gồm các lớp được dùng để biểu diễn các nút lệnh, cửa sổ, các trường văn
bản, v.v...
- Tầng kiến trúc vật lý: giải quyết vấn đề phần mềm sẽ thực hiện cụ thể trên
các máy tính và mạng như thế nào. Tầng này bao gồm các lớp xử lý sự giao tiếp

17


giữa hệ thống với hệ điều hành và mạng, các lớp xử lý việc giao tiếp với các ứng
dụng trung gian (middleware application) như DCOM của Micosoft hay các kiến
trúc .NET.

17


Gói và biểu đồ gói

18


Gói và biểu đồ gói
- Gói là một cấu trúc tổng quát dùng để nhóm các đơn vị (units) trong hệ thống lại với
nhau.
- Được sử dụng để giảm sự phức tạp của các mơ hình
- Một biểu đồ gói chỉ bao gồm các gói, các kí hiệu trong biểu đồ bao gồm:
Một gói:
- Là một nhóm các phần tử của UML có quan hệ logic với nhau.
- Được sử dụng để đơn giản hóa các biểu đồ UML bằng cách nhóm các phần
tử coa quan hệ với nhau thành một phần tử mới ở cấp cao hơn.

Quan hệ phụ thuộc:
- Biểu diễn sự phụ thuộc giữa các gói, nghĩa là nếu một gói bị thay đổi,
gói phụ thuộc cũng có thể phải sửa đổi
- Mũi tên sẽ hướng từ gói phụ thuộc vào gói mà nó phụ thuộc

19


Ví dụ biểu đồ gói biểu diễn sự phụ thuộc giữa 5 tầng của kiến trúc phần mềm:
- Sự thay đổi ở tầng Miền bài toán (Problem domain) sẽ dẫn tới sự thay đổi của
tầng giao diện (HCI), tầng kiến trúc vật lý, tầng quản lý dữ liệu.
- Sự thay đổi của tầng cơ sở sẽ dẫn tới sự thay đổi ở các tầng giao diện, miền bài
toán, kiến trúc vật lý và quản lý dữ liệu.
- V.v…
Hình 8-15 trang 296 mơ tả thêm mơt biểu đồ gói trong hệ thống Đặt lịch hẹn khám
bệnh.

20


Các bước xây dựng biểu đồ gói:
• Bước một, thiết lập phạm vi của sơ đồ gói. Gói có thể được sử dụng để mơ hình các
phần của hệ thống và/hoặc các tầng.
• Bước hai, phân nhóm các lớp thành các phần khác nhau dựa trên các quan hệ chia
sẻ giữa các lớp. Các quan hệ bao gồm tổng quát hóa, kết hợp, liên kết và việc gửi
thơng điệp diễn ra giữa các đối tượng trong hệ thống.
• Bước ba, đặt mỗi nhóm các lớp được chia vào một gói.

• Bước bốn, xác định mối quan hệ phụ thuộc giữa các gói.
• Bước năm, vẽ các đường hệ phụ thuộc giữa các gói vào sơ đồ gói.


21


Các chiến lược thiết kế hệ thống

22


Tự phát triển phần mềm
- Cho phép đáp ứng các yêu cầu chuyên môn cao
- Cho phép linh hoạt và sáng tạo trong việc giải quyết các vấn đề
- Dễ dàng thay đổi các thành phần
- Xây dựng được kỹ năng cá nhân
- Có thể đánh thuế các nguồn tài nguyên của công ty
- Rủi do trong xây dựng hệ thống tăng lên đáng kể

23


×