Giáo trình Phân tích và thiết kế hệ thống thông tin: Phần 2 - Trần Đình Quế

Giáo trình Phân tích và thiết kế hệ thống thông tin - Phần 1 trình bày các bước trong thiết kế hệ thống, chọn topo hệ thống mạng cho thiết kế, một số chủ đề về công nghệ, thiết kế đồng thời và an toàn hệ thống. Phần 2 giáo trình cũng trình bày ánh xạ mô hình lớp phân tích thành mô hình lớp thiết kế, xử lý lưu trữ với cơ sở dữ liệu quan hệ, một số vấn đề liên quan đến giao diện người sử dụng, thiết kế các dịch vụ nghiệp vụ, sử dụng pattern, framework và thư viện. Mời các bạn cùng tham khảo.
Nội dung trích xuất từ tài liệu:
Giáo trình Phân tích và thiết kế hệ thống thông tin: Phần 2 - Trần Đình Quế CHƯƠNG 5. THIẾT KẾ KIẾN TRÚC HỆ THỐNG CHƯƠNG 5 THIẾT KẾ KIẾN TRÚC HỆ THỐNG 5.1 GIỚI THIỆU Mục đích của pha phân tích là hình dung ra nghiệp vụ cần gì, trong khi mục đích của pha thiết kế là quyết định cách xây dựng hệ thống. Hay nói một cách khác, phân tích là nhằm trả lời câu hỏi “cái gì”, còn thiết kế là để trả lời câu hỏi “như thế nào”. Hoạt động chính của pha thiết kế là tiến hóa tập biểu diễn phân tích thành tập biểu diễn thiết kế. Trong pha này, nhóm dự án xem xét cẩn thận hệ thống mới sẽ hoạt động và được tích hợp như thế nào trong môi trường và hệ thống hiện thời. Nhóm cần phải xem xét nhiều chiến lược thiết kế và quyết định chiến lược nào sẽ được sử dụng. Ví dụ, xây dựng từ đầu, mua và địa phương hóa hay để bên ngoài xây dựng một phần. Mặc dù ranh giới giữa hai pha phân tích và thiết kế là không rõ ràng, nhưng rõ rang IT các tiến trình hoạt động của những pha này cần những ý tưởng hoàn toàn khác nhau. Sự mờ nhạt của ranh giới này có thể là cố ý như trong phương pháp luận phát triển lặp và tăng dần RUP, hoặc là ngẫu nhiên do nhóm phát triển phần mềm chưa có kinh nghiệm. T Nhiều kinh nghiệm và nghiên cứu đã chỉ ra rằng việc tách biệt rõ ràng giữa phân tích và thiết kế là ý tưởng tốt nhằm chắc chắn rằng vấn đề được hiểu rõ ràng trước khi xem xét các giải pháp. P Không có một quy tắc nào cho việc chuyển từ mô hình phân tích sang một mô hình thiết kế. Vì nó là quá trình có tính sáng tạo liên quan đến kinh nghiệm của nhóm phát triển, có được công nghệ để sử dụng lại, sở thích cá nhân…Một khi đã hiểu rõ được sản phẩm của các pha xác định yêu cầu và phân tích, người thiết kế có thể bắt đầu với một tờ giấy trắng để tiến hành pha thiết kế. Nghĩa là chúng ta không quan tâm về việc có chăng sự tương thích giữa những đối tượng phân tích và những đối tượng thiết kế, mà chú trọng hơn vào vấn đề thiết kế có dẫn tới một giải pháp hiệu quả không. Trong pha thiết kế, chúng ta phải đề xuất công nghệ lựa chọn cho thiết kế và xem xét mức độ tác động của các lựa chọn này như thế nào tới các thư viện, các mẫu (pattern) và các khuôn mẫu (framework) có sẵn của chúng ta và thậm chí những ghi chú UML chi tiết mà chúng ta dùng. Rõ ràng rằng thiết kế càng được tổng quát hơn thì càng ít gắn bó với một công nghệ cụ thể hơn. Điều này sẽ giảm bớt yêu cầu các nhà phát triển phải thành thạo nhiều công nghệ và đảm bảo chúng ta tránh được công nghệ lỗi thời. Tuy nhiên, 123 CHƯƠNG 5. THIẾT KẾ KIẾN TRÚC HỆ THỐNG mặt trái của việc thiết kế tổng quát là chúng ta có thể không lợi dụng được những lợi ích từ công nghệ cụ thể mà nó đem lại. Lịch sử đã chứng minh rằng nhiều công nghệ xuất hiện và biến mất thường xuyên hơn những lý thuyết làm cơ sở cho các công nghệ đó. Ví dụ, nhiều công nghệ ra đời dựa trên các ngôn ngữ lập trình như COBOL, Fortran, Pascal, Ada, Modula, PL/I, C, C++, Smalltalk, Eiffel, C# và Java, nhưng các công nghệ này bị chi phối chỉ bới hai lý thuyết lập trình hướng cấu trúc và lập trình hướng đối tượng. Vì vậy, rất hợp lý khi cho rằng “tổng quát thì an toàn hơn cụ thể”. Vì phát triển phần mềm hướng đối tượng được tiến hành theo kiểu tăng dần, nên chúng ta không hy vọng có thể có một thiết kế đầy đủ cả hệ thống ngay từ đầu. Vì thế, lúc bắt đầu pha thiết kế, chúng ta cần lên kế hoạch cho những phần của hệ thống mà chúng ta sẽ thiết kế. Những mức ưu tiên ca sử dụng sẽ giúp chúng ta đánh dấu những ca sử dụng nào là cần thiết nhất. Như trình bày trong Chương 3, các ca sử dụng màu xanh phải được thiết kế đầy đủ ngay; các ca sử dụng màu vàng thì chưa cần thiết kế ngay nhưng phải được hỗ trợ; ca sử dụng màu đỏ không phải thiết kế, nhưng chúng vẫn nên IT được hỗ trợ (“được thiết kế” có nghĩa là một giải pháp được đưa ra; “được hỗ trợ” có nghĩa là có một giải pháp hợp lý để dự phòng sau này. Trong thực tiễn, chúng ta sẽ tìm một kiến trúc hệ thống mà sẽ hỗ trợ một giải pháp T sao hiệu quả, thực tế cho tất cả ca sử dụng. Khi đó, chúng ta sẽ tiến hành thiết kế chi tiết cho hầu hết các ca sử dụng quan trọng và thiết kế một phần cho các ca sử dụng ít quan trọng hơn. Giữa những tiến trình lặp lại, chúng ra sẽ điều chỉnh các mức ưu tiên sao cho P hợp lý. Phần còn lại trong Chương này trình bày các bước trong pha thiết kế và sau đó tập trung xem xét cách tiến hành các bước trong giai đoạn thiết kế hệ thống thế nào. Giai đoạn thiết kế các hệ thống con sẽ được trình bày trong chương tiếp theo. 5.2 CÁC BƯỚC TRONG PHA THIẾT KẾ Pha thiết kế có thể được chia làm hai giai đoạn: Thiết kế hệ thống (hay Thiết kế kiến trúc hay Thiết kế tổng thể) và thiết kế hệ thống con (hay Thiết kế chi tiết). Thiết kế hệ thống bắt chúng ta phải có cái nhìn tổng quát về các tác vụ trước khi đi sâu vào thiết kế chi tiết các hệ thống con (sẽ được giới thiệu trong Chương 6). Thật ra, trong phương pháp hướng đối tượng, không có ranh giới giữa thiết kế hệ thống và thiết kế chi tiết nhưng việc phân biệt hai giai đoạn này là cần thiết. Thiết kế bao gồm các hoạt động sau đây: Thiết kế hệ thống 1. Lựa chọn công nghệ mạng cho hệ thống 2. Thiết kế tương tranh và an toàn-bảo mật 124 CHƯƠNG 5. THIẾT KẾ KIẾN TRÚC HỆ THỐNG 3. Phân rã hệ thống thành các hệ thống con 4. Xây dựng biểu đồ gói Thiết kế hệ thống con 1. Xây dựng biểu đồ lớp thiết kế 2. Xây dựng biểu đồ tuần tự 3. Xây dựng lược đồ cơ sở dữ liệu 5.3 LỰA CHỌN CÔNG NGHỆ MẠNG CHO HỆ THỐNG Việc lựa chọn công nghệ mạng sẽ chỉ ra cách hệ thống được phân rã thành các thành phần logic và vật lý riên ...