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

Chia sẻ: Tình Thiên | Ngày: | Loại File: PDF | Số trang:33

Thêm vào BST

Báo xấu

33
lượt xem 3
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

"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

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Bài giảng Chương 7: Chuyển từ giai đoạn phân tích sang giai đoạn thiết kế

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 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. 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 quá 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
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). 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ế 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. 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 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. 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