Systems Analysis and Design - Chapter 7: Moving on to Design - Lê Thị Tú Kiên

Nội dung text: Systems Analysis and Design - Chapter 7: Moving on to Design - Lê Thị Tú Kiên

1. Chuyển từ giai đoạn phân tích sang giai đoan thiết kế 1
2. 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
3. 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
4. Kiểm duyệt các mô hình phân tích 4
5. 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
6. 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
7. 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
8. 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
9. 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
10. 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
11. 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
12. 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
13. 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
14. 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
15. 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
16. 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
17. 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
18. 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
19. 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
20. Gói và biểu đồ gói 18
21. 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
22. 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
23. 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
24. Các chiến lược thiết kế hệ thống 22
25. 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
26. 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
27. 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” 25
28. 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 • Có thể mở rộng nguồn lực hiện có • Không bao giờ thuê gia công những gì bạn không hiểu • Chọn nhà cung cấp cẩn thận • Chuẩn bị hợp đồng và cách thanh toán cẩn thận 26
29. 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í. 27
30. Đọc thêm. 28
31. Ma trận Thay thế 29
32. Tổng kết chương 31