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ài giảng Chương 7: Chuyển từ giai đoạn phân tích sang giai đoạn thiết kế được biên soạn giúp các bạn nắm được mục đích của quá 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ì. quá 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

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

Giới thiệu

- Mục đích của quá 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 quá 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, thuê công ty khác xây phần mềm

- Có thể tạo được ma trận lựa chọn

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 quá

- 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

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ử

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

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ệ

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

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

Quá 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)

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ế toá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

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 toá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

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

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

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

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ể

Mua phần Phần mềm đã được viết sẵn:

Phần mềm được viết sẵn

Có thể hiệu quả hơn

Có thể được kiểm tra kỹ lưỡng hơn và được chứng minh(kiểm chứng)

Có thể lựa chọn các thành phần hoặc toàn bộ hệ thống

Phải chấp nhận các chức năng được cung cấp

Có thể yêu cầu thay đổi các quy trình nghiệp vụ của công ty

Có thể yêu cầu rất nhiều việc liên quan đến điều chỉnh và giải quyết các vấn đề liên

quan

24

Sự tích hợp hệ thống:

• Quá trình kết hợp các gói, hệ thống kế thừa và phần mềm mới

• Thách thức chính là tích hợp dữ liệu

• Ghi dữ liệu trong cùng một định dạng

• Sửa đổi các định dạng dữ liệu hiện có

• Phát triển “object wrappers”

Gia công phần mềm (thuê công ty ngoài phát triển phần mềm):

• Thuê công ty bên ngoài để tạo ra hệ thống

• Có thể có nhiều kỹ năng hơn

Lựa chọn một chiến lược thiết kế

Dựa trên các tiêu chí:

- Yêu cầu nghiệp vụ

- Kinh nghiệm nội bộ

- Kỹ năng phát triển dự án

- Quản lý dự án

- Khung thời gian

Trên Slide là bảng lựa chọn chiến lược thiết kế phần mềm dựa trên các tiêu chí

Đọc thêm

28

Ma trận Thay thế

Tổng kết chương