CHƯƠNG 1 TỔNG QUAN PHÂN TÍCH VÀ THIẾT KẾ HTTT OVERVIEW OF ANALYSIS AND DESIGN INFORMATION SYSTEMS PGS.TS. Nguyễn Mậu Hân Khoa CNTT-ĐHKH HUẾ nmhan2009@gmail.com 1 NỘI DUNG 1.1. CÁC KHÁI NIỆM VỀ THÔNG TIN VÀ HTTT 1.2. HỆ THỐNG THÔNG TIN QUẢN LÝ 1.3. MÔ HÌNH HÓA MỘT HTTT 1.4. GIỚI THIỆU MỘT VÀI PHƯƠNG PHÁP PTTK 1.5. CÁC MỨC BẤT BIẾN CỦA MỘT HTTT 1.6. CÁC CÁCH TIẾP CẬN TRONG PHÁT TRIỂN PHẦN MỀM 1.1. CÁC KHÁI NIỆM VỀ THÔNG TIN VÀ HTTT • Thông tin (Informations):  những sự kiện  những khái niệm  những hiểu biết và  những phán đoán có được ở một thời điểm ấn định về một hiện tượng, một sự việc hay một con người. 3 1.1. CÁC KHÁI NIỆM CƠ BẢN VỀ THÔNG TIN VÀ HTTT • Hệ thống - Hệ thống thông tin Hệ thống Tập hợp các phần tử có quan hệ qua lại với nhau cùng hoạt động hướng đến một mục tiêu chung thông qua việc tiếp nhận các đầu vào và sản xuất các đầu ra nhờ một quá trình chuyển đổi được tổ chức. Hệ thống này còn được gọi là hệ thống động (Dynamic System) 4 1.1. CÁC KHÁI NIỆM VỀ THÔNG TIN VÀ HTTT Hệ thống mở (hệ thống có tính xác suất) trong đó đầu vào, đầu ra không thể xác định chính xác nhưng có thể dự đoán được. Ví dụ: • Hệ thống đặt chổ vé máy bay không thể đoán chính xác bao nhiêu chỗ sẽ được đặt cho một chuyến bay nào đó. • Hệ thống thông tin dự báo thời tiết 5 1.1. CÁC KHÁI NIỆM VỀ THÔNG TIN VÀ HTTT Hệ thống đóng Hệ thống có thể đoán trước kết quả đầu ra nếu biết đầu vào. Vd: HTTT QL NHÂN SỰ & TIỀN LƯƠNG  hệ thống đóng dễ quản lý hơn hệ thống mở. Cấu tạo của một hệ thống INPUT SYSTEM OUTPUT HỘP ĐEN 6 1.1. CÁC KHÁI NIỆM VỀ THÔNG TIN VÀ HTTT Thông tin và Ra quyết định Mục đích của thông tin:  giúp nhà quản lý / lãnh đạo RQĐ. Ra Quyết định  một hành động (hay sự thực hiện) nhằm thay đổi trạng thái hiện tại tới 1 trạng thái mong muốn. Các loại quyết định:  QĐ có cấu trúc  QĐ bán cấu trúc  QĐ không có cấu trúc 1.1. CÁC KHÁI NIỆM VỀ THÔNG TIN VÀ HTTT Hệ thống thông tin (information system) Về hình thức- là một hệ thống, gồm nhiều thành phần mà mối liên hệ giữa các thành phần này cũng như liên hệ giữa chúng với các hệ thống khác là liên hệ thông tin. Về nội dung - Là một hệ thống sử dụng công nghệ thông tin để thu thập, truyền, lưu trữ, xử lý và biểu diễn thông tin trong một hay nhiều quá trình nghiệp vụ. 8 1.1. CÁC KHÁI NIỆM VỀ THÔNG TIN VÀ HTTT Tại sao phải phân tích thiết kế HT thông tin?  Có một cái nhìn đầy đủ, đúng đắn và chính xác về hệ thống thông tin được xây dựng.  Tránh sai lầm trong thiết kế và cài đặt.  Tăng vòng đời (life cycle) của hệ thống  Dễ sửa chữa, bổ sung và phát triển hệ thống. 9 1.1. CÁC KHÁI NIỆM VỀ THÔNG TIN VÀ HTTT IBM đã thống kê được trong giai đoạn 1970-1980. Phân tích về sai sót:  Quan niệm : 45%  Mã hóa : 25%  Soạn thảo : 7%  Các sai sót ở mức 2 : 20%  Các sai sót không xếp loại : 3% 10 1.1. CÁC KHÁI NIỆM VỀ THÔNG TIN VÀ HTTT IBM đã thống kê được trong giai đoạn 1970-1980. Phân tích về chi phí   Bảo trì: Phát triển: 54% 46% Phân tích phân bổ hoạt động    Sản xuất mã: Phát hiện và sửa chữa sai sót: Khác: 15% 50% 35% 11 1.1. CÁC KHÁI NIỆM VỀ THÔNG TIN VÀ HTTT Microsoft đã thống kê được (2003) 12 1.1. CÁC KHÁI NIỆM VỀ THÔNG TIN VÀ HTTT 13 1.1. CÁC KHÁI NIỆM VỀ THÔNG TIN VÀ HTTT Nhận xét: Các số liệu trên cho thấy:  Sai sót lớn nhất trong tất cả các loại sai sót:  Chi phí chiếm tỉ trọng lớn nhất: mức quan niệm, tức là nằm trong việc PT và TK. bảo hành  Lượng công việc chiếm tỷ lệ lớn nhất: phát hiện và sửa chữa. 14 ĐỊNH NGHĨA HÌNH THỨC MỘT HTTT  Hệ thống thông tin của một tổ chức là tập hợp các phương tiện, nhân lực, vật lực, thông tin và phương pháp xử lý tin nhằm cung cấp các thông tin cho quá trình ra quyết định đúng thời hạn và đủ độ tin cậy. 15 CÁC THÀNH PHẦN CỦA MỘT HTTT QUẢN LÝ Trong đó: *Tổ chức: có thể là cơ quan, xí nghiệp, trường học... *Phương tiện (phần cứng-phần mềm): cơ sở vật chất dùng để thu nhập, xử lý, lưu trữ, chuyển tải thông tin trong hệ thống như máy tính, máy in, điện thoại ... *Nhân lực: bao gồm tập thể, cá nhân tham gia vào việc phát triển và duy trì HT *Thông tin: Các thông tin sử dụng trong hệ thống, các thông tin từ môi trường bên ngoài vào hệ thống, các thông tin từ hệ thống ra môi trường bên ngoài. *Phương pháp xử lý tin: các tài nguyên phi vật chất như các mô hình toán học, các thuật toán, tri thức của con người trong hệ thống, các phần mềm. 16 1.2. HỆ THỐNG THÔNG TIN QUẢN LÝ (Management Information System, MIS) Mục đích của MIS  Phục vụ cho công tác quản lý.  Tạo ra các báo cáo thường xuyên hoặc theo yêu cầu dưới dạng tóm tắt về hiệu quả hoạt động nội bộ của tổ chức.  MIS chỉ quan tâm đến hiệu quả hoạt động của các đối tượng trong và ngoài tổ chức để có các biện pháp đối xử và phân bổ nguồn lực thích hợp. 1.2. HỆ THỐNG THÔNG TIN QUẢN LÝ (Management Information System, MIS) Chức năng của MIS – Cung cấp thông tin cho việc quản lý tổ chức – Cho phép các nhà quản lý kiểm soát và điều khiển các tổ chức – Cung cấp những thông tin phản hồi chính xác – Cung cấp các báo cáo đặc biệt trên cơ sở đã được lập kế hoạch 1.2. HỆ THỐNG THÔNG TIN QUẢN LÝ Đặc điểm MIS  MIS Hỗ trợ cho trong xử lý và lưu trữ giao dịch  MIS sử dụng CSDL hợp nhất và hỗ trợ cho nhiều chức năng trong tổ chức  MIS đủ mềm dẻo để có thể thích ứng được với những nhu cầu về thông tin của tổ chức  MIS tạo lớp vỏ an toàn cho HT và phân quyền cho việc truy nhập HT  MIS cung cấp thông tin theo thời gian cho các nhà QL, chủ yếu là các thông tin có cấu trúc 1.2. HỆ THỐNG THÔNG TIN QUẢN LÝ Ví dụ về HTTT quản lý 1.2. HỆ THỐNG THÔNG TIN QUẢN LÝ Một số MIS thông dụng: Dự báo bán hàng (Sales forecasting) Dự báo & quản lý tài chánh (Financial management and forecasting) Lập lịch & lập kế hoạch sản xuất (Manufacturing planning and scheduling) Lập kế hoạch & quản lý tồn kho (Inventory management and planning) Định giá sản phẩm & Quảng cáo (Advertising and product pricing) CÁC THÀNH PHẦN CỦA MỘT HTTT QUẢN LÝ Có 3 thành phần:  Thành phần quyết định: Chức năng: ra quyết định.  Thành phần thông tin: Chức năng tiếp nhận, xử lý, truyền tin và lưu trữ thông tin.  Thành phần tác nghiệp: Chức năng: bảo đảm các hoạt động cơ sở của tổ chức. 22 CÁC THÀNH PHẦN CỦA MỘT HTTT QUẢN LÝ 23 CÁC THÀNH PHẦN CỦA MỘT HTTT QUẢN LÝ VAI TRÒ, NHIỆM VỤ CỦA HTTT QUẢN LÝ Vai trò  Hệ thông tin đóng vai trò trung gian giữa hệ quyết định và hệ tác nghiệp trong hệ thống quản lý. Nhiệm vụ  Trao đổi thông tin với môi trường ngoài  Thực hiện việc liên lạc giữa các bộ phận và cung cấp thông tin cho các thành phần tác nghiệp và thành phần quyết định. 24 CÁC THÀNH PHẦN CỦA MỘT HTTT 25 1.3. MÔ HÌNH HÓA MỘT HỆ THỐNG THÔNG TIN Mô hình hóa là gì?  Mô hình hóa (MHH) là đơn giản hóa cái có thật  Mô hình là một dạng trừu tượng hoá hệ thống thực của bài toán mà chúng ta đang xét.  Bài toán này được diễn đạt một cách hình thức, dễ hiểu bằng văn bản, biểu đồ, đồ thị, công thức hay phương trình toán học, ...  Tóm lại, Mô hình là một cách mô tả của một vật thể nào đó. Vật đó có thể tồn tại trong một số giai đoạn nhất định của quá trình phân tích thiết kế hệ thống. Ví dụ về mô hình hóa Mô hình: Quả địa cầu học sinh Thế giới thực Thế giới thực Ôtô Làm chủ Con người Đọc  Sách Mô hình Ví dụ về mô hình A model is a complete description of a system from a particular perspective 1.3. MÔ HÌNH HÓA MỘT HỆ THỐNG THÔNG TIN... Tại sao phải mô hình hóa HTTT?  Nhu cầu của người phân tích thiết kế hệ thống  Tìm hiểu quá trình nhận thức, diễn tả sự phức tạp của hệ thống thông qua mô hình.  Giới hạn vấn đề nghiên cứu bằng cách chỉ tập trung vào một khía cạnh trong phạm vi không gian và thời gian nhất định. 1.3. MÔ HÌNH HÓA MỘT HỆ THỐNG THÔNG TIN... Mục đích của mô hình hoá  Giúp trực quan hóa hệ thống mà bạn muốn tìm hiểu.  Mô hình hóa cho phép đặc tả được cấu trúc và hành vi của hệ thống:  Đảm bảo hệ thống đạt được mục đích đã xác định trước.  Kiểm tra được các qui định về cú pháp, ngữ nghĩa, tính chặt chẽ và đầy đủ của mô hình, khẳng định được tính đúng đắn của thiết kế, phù hợp với yêu cầu đặt ra. 1.3. MÔ HÌNH HÓA MỘT HỆ THỐNG THÔNG TIN... Tóm lại, 4 mục đích quan trọng của mô hình hoá ...  Hình dung một hệ thống theo thực tế hay theo mong muốn của chúng ta.  Cho phép đặc tả cấu trúc hoặc hành vi của hệ thống.  Tạo một khuôn mẫu hướng dẫn nhà phát triển trong suốt quá trình xây dựng hệ thống.  Lập tài liệu về các quyết định đã đưa ra để sử dụng sau này. 1.3. MÔ HÌNH HÓA MỘT HỆ THỐNG THÔNG TIN... Các yêu cầu của mô hình hoá: Việc biểu diễn mô hình phải thỏa mãn các yếu tố sau: Chính xác (accurate): Mô tả đúng hệ thống cần xây dựng. Đồng nhất (consistent): Các view khác nhau không được mâu thuẩn với nhau. Có thể hiểu được (understandable): Cho những người xây dựng lẫn sử dụng Dễ thay đổi (changeable) Dễ dàng liên lạc với các mô hình khác. MỤC ĐÍCH, YÊU CẦU ĐỐI VỚI MỘT PH PHÁP PTTK Mục đích:  HTTT có vòng đời dài (long life cycle)  Có chức năng là một hệ hỗ trợ ra quyết định  Chương trình dễ cài đặt, sửa chữa, bảo hành  Hệ thống dễ sử dụng, có độ chính xác cao. MỤC ĐÍCH, YÊU CẦU ĐỐI VỚI MỘT PH PHÁP PTTK Yêu cầu Quan điểm tiếp cận tổng thể: Từ tổng quát đến chi tiết Xem mọi bộ phận, dữ liệu, chức năng là các phần tử trong hệ thống. Quan điểm top-down: Quan điểm phân tích từ trên xuống theo hướng tiếp cận từ tổng thể đến riêng biệt. Nhận dạng được các mức trừu tượng và bất biến của hệ thống ứng với chu trình phát triển hệ thống Nhận dạng được các thành phần dữ liệu và xử lý của HT Định ra được các kết quả cần đạt được cho từng giai đoạn phát triển hệ thống và các thủ tục cần thiết trong mỗi giai đoạn. XÂY DỰNG THÀNH CÔNG MỘT HTTT Khái niệm về một dự án CNTT thành công Chưa có một tiêu chuẩn cụ thể để xác định một HTTT được xem là thành công Một HTTT được gọi là có hiệu lực nếu nó góp phần nâng cao chất lượng hoạt động quản lý tổng thể của tổ chức, và thể hiện cụ thể trên các mặt: Đạt được mục tiêu thiết kế đề ra. Chi phí vận hành là chấp nhận được. Có độ tin cậy cao, đáp ứng được các chuẩn mực của một HTTT Sản phẩm có giá trị: thtin đưa ra là đúng đắn, kịp thời, có ý nghĩa thiết thực đối với hoạt động chức năng và quản lý. Dễ học, dễ nhớ và dễ sử dụng. Mềm dẽo, hướng mở, dễ bảo trì. 1.4. GIỚI THIỆU MỘT VÀI PHƯƠNG PHÁP PTTK Một số công cụ mô tả quá trình phát triển một HTTT: Lưu đồ hệ thống: đồ thị về những đầu vào (input), đầu ra (output) và dòng dữ liệu giữa các điểm chính trong hệ thống. Sơ đồ khối chương trình: đồ thị về lôgic dòng điều khiển của chương trình. Sơ đồ ngữ cảnh: mô tả các dòng dữ liệu lưu chuyển giữa các thành phần (điểm công tác) khác nhau của hệ thống. Từ điển dữ liệu: tập hợp có cấu trúc các dữ kiện về dữ liệu. Từ điển dữ liệu chứa danh sách các cấu trúc dữ liệu và các định nghĩa về tất cả thành phần dữ liệu cơ sở trong các kho dữ liệu. Lược đồ cấu trúc: đồ thị về lôgic điều khiển các chức năng của hệ thống. 1.4. GIỚI THIỆU MỘT VÀI PHƯƠNG PHÁP PTTK Phương pháp phân tích thiết kế có cấu trúc SADT: Nguồn gốc: xuất phát từ Mỹ, Ý tưởng cơ bản:  Một hệ thống được xem như một bộ sưu tập của các chức năng.  Phân rã một hệ thống lớn thành các hệ thống con đơn giản. 1.4. GIỚI THIỆU MỘT VÀI PHƯƠNG PHÁP PTTK Phương pháp phân tích thiết kế SADT: Công cụ để phân tích:  Sơ đồ chức năng nghiệp vụ BFD (Business Function Diagram)  Sơ đồ luồng dữ liệu DFD (Data Flow Diagram) .  Mô hình dữ liệu quan hệ (Relation data Mode)  Ngôn ngữ có cấu trúc (Structured Language)  Từ điển dữ liệu (Data Dictionary)  Bảng và cây quyết định (Warnier/orr)  Đặc tả các tiến trình (Process Specification). Ưu điểm:  Dựa vào nguyên lý phân tích có cấu trúc  Thiết kế theo lối phân cấp, bảo đảm từ một dữ liệu vào sản xuất nhiều dữ liệu ra. Nhược điểm:  không chứa toàn bộ các tiến trình phân tích do đó nếu không thận trọng có thể đưa đến tình trạng trùng lặp thông tin. 1.4. GIỚI THIỆU MỘT VÀI PHƯƠNG PHÁP PTTK Phương pháp phân tích thiết kế MERISE: Nguồn gốc: MERISE viết tắt từ cụm từ Methode pour Rassembler les Ideés Sans Effort (phương pháp tập hợp các ý tưởng không cần cố gắng). Ra đời vào những năm cuối của thập niên 70. Xuất phát từ những suy nghĩ của một nhóm nghiên cứu đứng đầu bởi J.L.Lemoigne tại trường đại học AixEn-Provence - Pháp và những nghiên cứu hiện thực đồng thời ở Trung tâm nghiên cứu trang bị kỹ thuật (CETE), dưới sự lãnh đạo của H.Tardien. 1.4. GIỚI THIỆU MỘT VÀI PHƯƠNG PHÁP PTTK Phương pháp phân tích thiết kế MERISE: Nguồn gốc: MERISE viết tắt từ cụm từ Methode pour Rassembler les Ideés Sans Effort (phương pháp tập hợp các ý tưởng không cần cố gắng). Ra đời vào những năm cuối của thập niên 70. Xuất phát từ những suy nghĩ của một nhóm nghiên cứu đứng đầu bởi J.L.Lemoigne tại trường đại học AixEn-Provence - Pháp và những nghiên cứu hiện thực đồng thời ở Trung tâm nghiên cứu trang bị kỹ thuật (CETE), dưới sự lãnh đạo của H.Tardien. 1.4. GIỚI THIỆU MỘT VÀI PHƯƠNG PHÁP PTTK Phương pháp phân tích thiết kế MERISE: Đặc trưng của phương pháp Merise:  Tách rời dữ liệu và xử lý nhằm đảm bảo tính khách quan trong quá trình phân tích và cung cấp đầy đủ các mô hình để diễn đạt các bước cập nhật. Mô tả hệ thống: bao gồm dữ liệu và xử lý được biểu diễn ở ba mức:  Mức quan niệm (Concept): xác định mục đích của hệ thống, các thành phần của dữ liệu và xử lý.  Mức tổ chức (Oganization): chi tiết hóa những quan hệ giữa chúng.  Mức vật lý (Physic): các thành phần được thể hiện trong thực tế như thế nào. 1.4. GIỚI THIỆU MỘT VÀI PHƯƠNG PHÁP PTTK Phương pháp phân tích thiết kế MERISE: Công cụ để phân tích: MỨC DỮ LIỆU XỬ LÝ Mức quan niệm MH quan niệm về dữ liệu MH tổ chức về dữ liệu MH quan niệm về xử lý MH tổ chức về xử lý MH vật lý về dữ liệu MH vật lý về xử lý Mức tổ chức Mức vật lý 1.4. GIỚI THIỆU MỘT VÀI PHƯƠNG PHÁP PTTK Phương pháp phân tích thiết kế hướng đối tượng  Ra đời vào giữa thập niên 80  Phát triển từ các ý tưởng của lập trình hướng đối tượng.  Dựa trên một số khái niệm cơ bản sau: • Ðối tượng (Object): gồm dữ liệu và thủ tục tác động lên dữ liệu này • Lớp (Class): Tập hợp các đối tượng có chung một cấu trúc dữ liệu và cùng một phương pháp. • Kế thừa (Heritage): tính chất kế thừa là đặc tính cho phép định nghĩa một lớp mới từ các lớp đã có bằng cách thêm vào đó những dữ liệu mới, các phương pháp mới có thể kế thừa những đặc tính của lớp cũ. • Ðóng gói (Encapsulation): Không cho phép tác động trực tiếp lên dữ liệu của đối tượng mà phải thông qua các phương pháp trung gian. 1.4. GIỚI THIỆU MỘT VÀI PHƯƠNG PHÁP PTTK Phương pháp phân tích thiết kế hướng đối tượng (tt)  Sử dụng ngôn ngữ mô hình hoá hợp nhất UML để mô tả.  UML sử dụng 9 biểu đồ để mô hình hóa một hệ thống: NHỮNG SAI LẦM CÓ THỂ XẢY RA KHI PTTK MỘT HTTT  Thiếu sự tiếp cận tổng thể trong phát triển HT  Thu thập thông tin nhiều lần về một đối tượng  Dùng các thuật ngữ khác nhau đối với cùng một quan niệm  Sự phiến diện, không đầy đủ của hồ sơ  Sự bất hợp tác của người sử dụng.  Thiếu một chuẩn thống nhất: Người phân tích thiếu một chuẩn thống nhất để mô tả, cài đặt các ứng dụng trong hệ thống 1.4. CÁC GIAI ĐOẠN XÂY DỰNG MỘT HTTT TIN HỌC HÓA  Nghiên cứu nhu cầu (hệ thống cần gì?)  Nghiên cứu khả thi (cân nhắc giữa nhu cầu và khả năng)  Đề xuất một kiểu kiến trúc mới của HT  Mã hóa (tổ chức dữ liệu và lập trình)  Thử nghiệm và khai thác 1.4. CÁC GIAI ĐOẠN XÂY DỰNG MỘT HTTT TIN HỌC HÓA a. Giai đoạn lập kế hoạch (khảo sát hệ thống)  Xác định các công việc cần thiết trước khi có thể tiến hành nghiên cứu các lĩnh vực, bộ phận, hệ thống con, các tổ chức có liên quan đến hệ thống thông tin cần xây dựng.  Làm rõ được ý muốn của chủ đầu tư là: xây dựng 1 hệ thống thông tin mới hay nâng cấp một hệ thống thông tin cũ. b. Giai đoạn phân tích Là giai đoạn trung tâm khi xây dựng 1 hệ thống thông tin, giai đoạn này khởi sự ngay trong giai đoạn lập kế hoạch. Phân tích bao gồm các công việc sau: 1. Phân tích hiện trạng Mục đích: hiểu rõ tình trạng hoạt động của hệ thống cũ trong mục đích hoạt động của tổ chức. Nội dung công việc: Tìm hiểu hiện trạng: thông qua việc nghiên cứu hồ sơ, tài liệu để tìm hiểu thông tin chung về ngành dọc của tổ chức.  Tìm hiểu hoạt động hiện tại của tổ chức  Xác định các thành phần tham gia trong tổ chức  Các nhiệm vụ của các tổ chức thành viên và các tổ chức bên ngoài có liên quan  Các mối quan hệ thông tin giữa các thành viên trong tổ chức b. Giai đoạn phân tích 2. Phân tích khả thi và lập hồ sơ nhiệm vụ: . Phân tích khả thi về kỹ thuật: xem xét khả năng kỹ thuật hiện có để đề xuất giải pháp kỹ thuật áp dụng cho httt mới. . Phân tích khả thi kinh tế: xem xét khả năng tài chính để chi trả cho việc xây dựng hệ thống thông tin mới cũng như chỉ ra những lợi ích mà hệ thống sẽ đem lại. . Phân tích khả thi hoạt động: khả năng vận hành hệ thống trong điều kiện khuôn khổ, điều kiện tổ chức và quản lý cho phép của tổ chức. Tóm lại, trong giai đoạn này người phân tích phải tìm ra một điểm cân bằng giữa nhu cầu và khả năng. b. Giai đoạn phân tích Lập hồ sơ nhiệm vụ. Công việc này nhằm mục đích: • Định hình các chức năng hệ thống cần đạt được. • Định ra các thủ tục xây dựng quan niệm và thực hiện hệ thống • Định hình sơ lược giao diện của hệ thống với người sử dụng trong tương lai. • Làm các bản mẫu (prototype) để NSD hình dung được hệ thống trong tương lai. Tóm lại, lập hồ sơ nhiệm vụ là một thỏa thuận không chính thức giữa 3 phía: Người phân tích, Chủ đầu tư và Người sử dụng. c. Giai đoạn thiết kế  Thiết kế dữ liệu: xác định các đối tượng và cấu trúc dữ liệu được sử dụng trong hệ thống.  Thiết kế chức năng: định ra các modun xử lý thể hiện các chức năng xử lý của hệ thống thông tin.  Thiết kế giao diện: chi tiết hóa hình thức giao tiếp người - máy  Thiết kế an toàn hệ thống  Thiết kế phần cứng: tính toán các yêu cầu kỹ thuật, cơ sở vật chất cho hệ thống  Dự kiến nhân sự tại các vị trí công tác của hệ thống. d. Giai đoạn thực hiện xây dựng hệ thống bao gồm xây dựng các file cơ bản. viết các chương trình thực hiện các chức năng của hệ thống mới tương ứng với các kiểu khai thác đã đặt ra. làm tài liệu sử dụng để hướng dẫn cho người sử dụng làm tài liệu kỹ thuật cho các chuyên gia tin học phát triển hệ thống sau này. e. Giai đoạn chuyển giao hệ thống Hiệu chỉnh hệ thống Vận hành thử bằng số liệu giả để phát hiện sai sót Đưa hệ thống vào khai thác thử nghiệm Đào tạo người sử dụng tại mỗi vị trí trong hệ thống. Chuyển giao hệ thống f. Giai đoạn bảo trì hệ thống Sửa đổi, khắc phục những thiếu sót của hệ thống Làm cho hệ thống thích nghi hơn, thuận tiện hơn trong sử dụng. Quá trình xây dựng một HTTT có thể mô tả theo sơ đồ dưới đây: Sơ đồ mô tả quá trình phân tích và thiết kế một HTTT LẬP KẾ HOẠCH PHÂN TÍCH THIẾT KẾ THỰC HIỆN CHUYỂN GIAO BẢO TRÌ Mô hình thác nước - Water Fall Model Mô hình thác nước - Water Fall Model Giai đoạn phân tích Giai đoạn thiết kế Giai đoạn mã hóa Giai đoạn kiểm thử Giai đoạn bảo trì 1.5. CÁC MỨC BẤT BIẾN CỦA MỘT HTTT Xuất phát từ các nhu cầu: Cần có một mô hình hoặc một ngôn ngữ đặc tả đơn giản nhưng đơn nghĩa để xác định những yêu cầu trong mỗi giai đoạn phân tích. Cần có một mô hình hoặc một ngôn ngữ để đối thoại với những người không chuyên tin học trong hệ thống thông tin. Cần có một ngôn ngữ mô tả các mức quan niệm khác nhau của hệ thống thông tin liên quan đến chu kỳ sống của hệ thống. 1.5. CÁC MỨC BẤT BIẾN CỦA MỘT HTTT a. Mức quan niệm: 1. Ý nghĩa: Mô tả mục đích hệ thống thông tin và những ràng buộc phải tôn trọng trong mối quan hệ với mục đích của hệ thống. Các mô tả này phải độc lập với mọi giải pháp cài đặt 2. Những đối tượng cần phải mô tả ở mức quan niệm: • Các đối tượng được sử dụng trong hệ thống. • Các hiện tượng và các mối quan hệ thông tin giữa các đối tượng, giữa các hệ thống con trong hệ thống và giữa hệ thống với môi trường bên ngoài. • Thứ tự công việc được thực hiện trong hệ thống. • Các qui tắc biến đổi, công thức tính toán, thuật toán. • Các nhiệm vụ hệ thống phải thực hiện và các ràng buộc mà hệ thống phải tôn trọng. 1.5. CÁC MỨC BẤT BIẾN CỦA MỘT HTTT a. Mức quan niệm: Có 3 loại quy tắc: + Qui tắc quản lý: qui định mục tiêu và ràng buộc của hệ thống (thường là những quy định, luật lệ áp đặt từ môi trường ngoài). Một cách để xem xét một quy tắc có phải là quy tắc quản lý không là nếu hủy bỏ quy tắc này thì hệ thống có nguy cơ bị phá vỡ không? + Qui tắc tổ chức: qui tắc liên quan đến giải pháp họat động của hệ thống. + Qui tắc kỹ thuật: qui tắc liên quan đến các yêu cầu kỹ thuật để đảm bảo hệ thống có thể họat động được. 1.5. CÁC MỨC BẤT BIẾN CỦA MỘT HTTT a. Mức quan niệm: Ở mức quan niệm cần trả lời các câu hỏi: WHAT? Chức năng của hệ thống thông tin là gì? Hệ thống thông tin cần những yếu tố gì? Hệ thống có dữ liệu và những quy tắc quản lý gì? 1.5. CÁC MỨC BẤT BIẾN CỦA MỘT HTTT b. Mức tổ chức:  Mục đích: xác định các phương tiện, nhân lực, máy móc, cách tổ chức để cung cấp các thông tin cho người sử dụng đúng thời hạn và đủ độ tin cậy.  Tại mức này, cần trả lời các câu hỏi:  Ai làm? (WHO?)  Làm ở đâu? (WHERE?)  Làm khi nào? (WHEN?) Thông tin ở mức tổ chức được mô tả theo giải pháp CSDL và thực chất là quan hệ logic của chúng. Do đó, đối với dữ liệu mức tổ chức còn gọi là mức logic. 1.5. CÁC MỨC BẤT BIẾN CỦA MỘT HTTT c. Mức vật lý: Mục đích: Xác định cách thực hiện của hệ thống thông tin trong một môi trường cài đặt nào đó Đây là mức ít trừu tượng nhất vì nó chính là hệ thống có thể họat động và vận hành. Tại mức này, cần trả lời câu hỏi hệ thống hoạt động như thế nào? (HOW?) Thông tin ở mức vật lý được mô tả với các cấu trúc, giá mang và phương thức truy nhập. 1.6. CÁC CÁCH TIẾP CẬN TRONG PHÁT TRIỂN PHẦN MỀM 1. Cách tiếp cận theo hướng chức năng Đặc điểm:  Dựa vào chức năng là chính  Tập trung khảo sát chức năng, hành vi của hệ thống  Khi các chức năng của hệ thống đã được xác định thì chúng khó thay đổi trong suốt quá trình thiết kế  Dữ liệu sẽ được xác định cấu trúc dựa vào các chức năng 1.6.1 CÁCH TIẾP CẬN THEO HƯỚNG CHỨC NĂNG Đặc điểm:  Phân rã chức năng và làm mịn dần theo cách tiếp cận Top/Down  phân tách nhỏ các chức năng chính thành các chức năng đơn giản hơn theo cách từ trên xuống- nguyên lý chia để trị.  Kết quả của việc phân rã là một BFD của hệ thống  Các đơn thể chức năng trao đổi với nhau bằng cách truyền tham số hay sử dụng dữ liệu chung 1.6.1 CÁCH TIẾP CẬN THEO HƯỚNG CHỨC NĂNG Đặc điểm: Bị ảnh hưởng bới các ngôn ngữ lập trình ALGOL, Pascal, C Các hàm của hệ thống phần mềm được xem như tiêu chí cơ sở khi phân rã Tách chức năng khỏi dữ liệu Chức năng có hành vi Dữ liệu chứa thông tin bị các chức năng tác động Phân tách top-down chia hệ thống thành các hàm để chuyển sang mã trình, dữ liệu được gửi giữa chúng. 1.6.1 CÁCH TIẾP CẬN THEO HƯỚNG CHỨC NĂNG Hệ thống quản lý thư viện Quản lý bạn đọc quản lý tài liệu Dữ liệu chung Theo dõi mượn trả Dữ liệu chung Chức năng 1 Chức năng 2 Dữ liệu riêng Dữ liệu riêng Thống kê 1.6.2 CÁCH TIẾP CẬN THEO HƯỚNG ĐỐI TƯỢNG Đặc điểm:  Đặt trọng tâm vào dữ liệu (thực thể)  Xem hệ thống như là tập các thực thể, các đối tượng  Các lớp đối tượng trao đổi với nhau bằng các thông điệp  Tính mở và thích nghi của hệ thống cao  Hỗ trợ sử dụng lại và cơ chế kế thừa 1.6.2 CÁCH TIẾP CẬN THEO HƯỚNG ĐỐI TƯỢNG  Tiệm cận hướng đối tượng tập trung vào cả thông tin và hành vi  Cho khả năng xây dựng hệ thống mềm dẻo, “co dãn”  Phương pháp này dựa trên các nguyên tắc sau • Tính đóng gói • Kế thừa • Đa trị 1.6.3 NHẬN XÉT Ưu điểm chính của phương pháp HĐT  là cơ sở để kết hợp các đơn thể có thể sử dụng lại thành hệ thống lớn hơn, tạo ra những sản phẩm có chất lượng cao  Qui ước truyền thông điệp giữa các đối tượng đảm bảo cho việc mô tả các giao diện giữa các đối tượng thành phần bên trong hệ thống và những hệ thống bên ngoài trở nên dễ dàng hơn  Nguyên lý bao gói, che giấu thông tin hỗ trợ cho việc xây dựng những hệ thống thông tin an toàn. 1.6.3 NHẬN XÉT Ưu điểm chính của phương pháp HĐT:  Nguyên lý bao gói, che giấu thông tin hỗ trợ cho việc xây dựng những hệ thống thông tin an toàn.  Lập trình HĐT với kỹ thuật kế thừa cho phép dễ dàng xác định các đơn thể và sử dụng ngay khi chúng chưa thực hiện đầy đủ các chức năg (đơn thể mở) và sau đó mở rộng được mà không làm ảnh hưởng tới các đơn thể khác. 1.6.3 NHẬN XÉT Ưu điểm chính của phương pháp HĐT (tt)  Định hướng đối tượng cung cấp những công cụ, môi trường mới, hiệu quả để phát triển phần mềm theo hướng công nghiệp và hỗ trợ để tận dụng được những khả năng kế thừa, sử dụng lại ở phạm vi diện rộng để xây dựng được những hệ thống phức tạp như: hệ thống động, hệ thống thời gian thực, v,v.  Xoá bỏ được hố ngăn cách giữa các pha phân tích, thiết kế và cài đặt trong quá trình xây dựng phần mềm. Những hạn chế của phương pháp hướng CN Sản phẩm khó bảo trì Mọi chức năng đều chia sẻ khối dữ liệu lớn Các chức năng phải hiểu rõ dữ liệu được lưu trữ thế nào Khi thay đổi cấu trúc dữ liệu kéo theo thay đổi mọi hàm liên quan Tiến trình phát triển không ổn định Thay đổi yêu cầu kéo theo thay đổi các chức năng Rất khó bảo toàn kiến trúc thiết kế ban đầu khi hệ thống tiến hóa Không hỗ trợ lập trình bằng ngôn ngữ hướng đối tượng như C++, Java, Smalltalk, Eiffel. HẾT CHƯƠNG 1 82 CHƯƠNG 2 PHÂN TÍCH VÀ THIẾT KẾ HTTT THEO HƯỚNG CHỨC NĂNG ANALYSIS AND DESIGN INFORMATION SYSTEMS IN FUNCTIONAL-ORIENTED PGS.TS. Nguyễn Mậu Hân Khoa CNTT-ĐHKH HUẾ 83 NỘI DUNG 2.1. NGHIÊN CỨU HIỆN TRẠNG CỦA HTTT 2.2. PHÂN TÍCH HỆ THỐNG VỀ CHỨC NĂNG 2.3. MÔ HÌNH QUAN NIỆM CỦA HTTT 2.4. MÔ HÌNH TỔ CHỨC CỦA HTTT 2.5. MÔ HÌNH VẬT LÝ CỦA HTTT 2.6. THIẾT KẾ GIAO DIỆN, BÁO BIỂU, AN TOÀN HỆ THỐNG 2.1. NGHIÊN CỨU HIỆN TRẠNG CỦA HTTT 2.1.1. Mục đích: Tiếp cận với nghiệp vụ chuyên môn, môi trường hoạt động của hệ thống. Tìm hiểu các chức năng, nhiệm vụ và cách hoạt động của hệ thống. Chỉ ra các ưu điểm của hệ thống cũ để kế thừa và các khuyết điểm của hệ thống để nghiên cứu khắc phục. 85 2.1. NGHIÊN CỨU HIỆN TRẠNG CỦA HTTT 2.1.2. Nội dung khảo sát và đánh giá hiện trạng: Thu thập và mô tả các quy tắc quản lý, tổ chức, kỹ thuật. Thu thập và tìm hiểu các chứng từ giao dịch. Mô tả các luồng thông tin và tài liệu giao dịch. Thống kê các phương tiện và tài nguyên đã và có thể sử dụng. Thu thập và tìm hiểu các ý kiến khen chê về HTTT cũ và những yêu cầu, đòi hỏi về hệ thống tương lai. Lập hồ sơ tổng hợp về hiện trạng 86 2.1. NGHIÊN CỨU HIỆN TRẠNG CỦA HTTT 2.1.3. Nghiên cứu các tài liệu Qua các tài liệu của hệ thống phân tích viên có thể nắm được: các công việc, các chức năng, các quy tắc làm việc. Các tài liệu nghiên cứu bao gồm: Các văn bản pháp quy, quy định về chức năng, nhiệm vụ của tổ chức và của mỗi điểm công tác. Các văn bản pháp quy, quy định về tiêu chuẩn, quy tắc, phương thức làm việc. Các chủ trương chính sách mà tổ chức, mà nhà nước đã ban hành. Các báo cáo, báo biểu, thống kê đã có. 87 2.1. NGHIÊN CỨU HIỆN TRẠNG CỦA HTTT Tóm lại, phải trả lời cho được các câu hỏi sau: Hệ thống đang làm gì? Gồm những công việc gì? Đang quản lý cái gì? Những công việc trong hệ thống do ai làm? Làm ở đâu? Khi nào làm? Mỗi công việc được thực hiện như thế nào? Mỗi công việc liên quan đến dữ liệu nào? Chu kỳ, tần suất, khối lượng công việc? Đánh giá các công việc hiện tại: tầm quan trọng như thế nào? Các thuận lợi, khó khăn? Nguyên nhân dẫn đến khó khăn? 88 2.1. NGHIÊN CỨU HIỆN TRẠNG CỦA HTTT 2.1.2. Các công việc sau khảo sát hiện trạng: a. Xử lý sơ bộ kết quả khảo sát  Làm rõ các chức năng của hệ thống Xác định được các chức năng và dữ liệu của hệ thống: như các đối tượng, các điểm công tác, các hoạt động. Đối với mỗi chức năng cần làm rõ: điều kiện khởi động, kết quả thu được, thời gian thực hiện, tần số, chu kỳ, các quy tắc phải tuân thủ. 89 2.1. NGHIÊN CỨU HIỆN TRẠNG CỦA HTTT  Rà soát lại dữ liệu: Tên dữ liệu: do người phân tích lựa chọn Định nghĩa về dữ liệu: mô tả bằng lời hoặc bằng công thức Kiểu dữ liệu (số, chuỗi,...) Loại: là dữ liệu cơ sở hay dữ liệu được suy từ dữ liệu khác. Ràng buộc về giá trị 90 2.1. NGHIÊN CỨU HIỆN TRẠNG CỦA HTTT b. Tổng hợp kết quả khảo sát Tổng hợp các xử lý Mục đích là làm rõ các thiếu sót và sự rời rạc của các yếu tố liên quan đến công việc khi phỏng vấn. Có hai cách tổng hợp các xử lý: tổng hợp kết hợp với yếu tố tổ chức tổng hợp tách rời các yếu tố tổ chức. Tổng hợp các dữ liệu Mục tiêu là liệt kê ra tất cả các dữ liệu có liên quan đến hệ thống nhằm xây dựng một từ điển dữ liệu chung cho toàn nhóm phân tích. 91 2.1. NGHIÊN CỨU HIỆN TRẠNG CỦA HTTT c. Hợp thức hoá kết quả khảo sát Mục đích: xác định tính đúng đắn của thông tin và dữ liệu phản ánh yêu cầu thông tin của hệ thống bảo đảm tính pháp lý của nó cho việc sử dụng sau này. Hợp thức hoá kết quả khảo sát gồm các công việc: Hoàn chỉnh và trình bày các dữ liệu thu được để người sử dụng xem xét và cho ý kiến. Tổng hợp các tài liệu để các nhà quản lý và lãnh đạo đánh giá và bổ sung. Đề đạt thêm một số quy tắc mới (như các quy tắc về an toàn hệ thống, các yêu cầu về nhân sự,...) Hợp thức hoá là một khâu không thể bỏ qua, nếu không có thể 92 sẽ đối mặt với những khó khăn không lường khi triển khai. 2.1. NGHIÊN CỨU HIỆN TRẠNG CỦA HTTT Giới thiệu một số nghiên cứu hiện trạng a. Hệ thống thông tin "Quản lý kho hàng" Một công ty sản xuất bánh kẹo, có nhiều kho để chứa vật tư và hàng hoá: Kho nguyên liệu: chứa đường, bột, hương liệu, bao bì,... Kho nhiên liệu: chứa xăng, dầu, than Kho phụ tùng: chứa các thiết bị thay thế Kho thành phẩm: chứa bánh kẹo đã sản xuất được ....... (Xem tiếp trong giáo trình) 93 2.1. NGHIÊN CỨU HIỆN TRẠNG CỦA HTTT Giới thiệu một số nghiên cứu hiện trạng a. Hệ thống thông tin "Quản lý Công chức" Một cơ quan hành chính sự nghiệp cần tin học hoá việc quản lý cán bộ công chức của cơ quan mình. Qua nghiên cứu hiện trạng phân tích viên đã nắm được các thông tin sau: Mỗi công chức được cơ quan quản lý các thông tin sau đây: Họ tên, đơn vị công tác, giới tính, ngày sinh, nơi sinh, địa chỉ, dân tộc, tôn giáo, chính trị, trình độ văn hóa, ngoại ngữ, loại hình đào tạo, cựu chiến binh, ngày vào cơ quan, ngày vào biên chế, cha mẹ, vợ chồng, con, khen thưởng, kỷ luật. ....... (Xem tiếp trong giáo trình) 94 2.2. PHÂN TÍCH HỆ THỐNG VỀ CHỨC NĂNG 2.2.1. Các mức độ mô tả chức năng a. Mô tả vật lý : Mô tả chức năng ở mức độ vật lý đòi hỏi phải nói rõ mục đích và cách thực hiện của quá trình xử lý, nghĩa là phải trả lời câu hỏi: làm gì? và làm như thế nào? b. Mô tả logic: Mô tả chức năng ở mức độ logic lại đơn giản hơn, chỉ cần trả lời đầy đủ câu hỏi làm gì? Nghĩa là chỉ diễn tả mục đích, bản chất của quá trình xử lý mà không cần quan tâm đến các yếu tố về thực hiện, cài đặt như phương pháp, phương tiện, tác nhân, thời điểm, thời gian,... 95 2.2. PHÂN TÍCH HỆ THỐNG VỀ CHỨC NĂNG c. Mô tả đại thể và mô tả chi tiết: Ở mức độ đại thể Một chức năng được mô tả dưới dạng hộp đen. Nội dung bên trong hộp đen không được chỉ rõ mà chỉ mô tả các thông tin vào và ra hộp đen đó. Ở mức độ chi tiết Nội dung của quá trình xử lý phải được chỉ rõ hơn: Các chức năng con Các mối quan hệ thông tin và điều khiển giữa những chức năng đó. Nếu một chức năng có nhiều chức năng con thì để mô tả chi tiết người phân tích phải phân rã các chức năng con này thành nhiều mức. Các mức này được biểu diễn qua biểu đồ phân cấp chức 96 năng dưới đây. 2.2. PHÂN TÍCH HỆ THỐNG VỀ CHỨC NĂNG 2.2.2. Biểu đồ chức năng nghiệp vụ BFD (Business Function Diagram) BFD là một sơ đồ hình học dùng để mô tả sự phân rã có thứ bậc các chức năng của hệ thống từ đại thể đến chi tiết. Mỗi nút trong biểu đồ là một chức năng, các chức năng này có quan hệ bao hàm với nhau và chúng được nối với nhau bằng các cung để tạo nên một cấu trúc cây. Ký hiệu: một chức năng được biểu diễn bởi một hình chữ nhật hoặc một vòng tròn (SADT) <Tên chức năng> <Tên chức năng> 97 2.2. PHÂN TÍCH HỆ THỐNG VỀ CHỨC NĂNG Ví dụ: Biểu đồ chức năng nghiệp vụ của hệ thống thông tin “quản lý doanh nghiệp” Quản lý Doanh nghiệp Quản lý Nhân sự Quản lý Vật tư Tài sản cố định Thiết bị Quản lý Tài chính Lương tiền Kế toán 98 2.2. PHÂN TÍCH HỆ THỐNG VỀ CHỨC NĂNG Ví dụ: BFD về “Quản lý trông giữ xe” Quản lý trông giữ xe 1. Nhận xe 2. Trả xe 3. Giải quyết sự cố 2.1 Kiểm tra vé 3.1 Kiểm tra sổ gửi 1.2 Ktra chổ trống 2.2 Đối chiếu vé 3.2 Ktra hiện trường 1.3 Ghi vé xe 2.3 Thanh toán 3.3 Lập biên bản 1.4 Ghi số xe vào 2.4 Ghi số xe ra 3.4 Thanh toán sự cố 1.1 Nhận dạng xe 99 2.2. PHÂN TÍCH HỆ THỐNG VỀ CHỨC NĂNG 2.2.3. Mô hình hoá các tiến trình của hệ thống a. Biểu đồ luồng dữ liệu DFD (Data Flow Diagram ) DFD là một sơ đồ hình học nhằm diễn tả các luồng dữ liệu thông qua các chức năng của hệ thống. Những hỗ trợ của DFD Xác định yêu cầu của người dùng. Lập kế hoạch và minh hoạ những phương án cho phân tích viên và người dùng xem xét. Trao đổi giữa những phân tích viên và người dùng trong hệ thống. Làm tài liệu đặc tả yêu cầu hình thức và đặc tả thiết kế hệ thống. 100 2.2. PHÂN TÍCH HỆ THỐNG VỀ CHỨC NĂNG b. Các thành phần của một DFD: Luồng dữ liệu (Data flow): Một luồng dữ liệu là một tuyến truyền dẫn thông tin vào hay ra một chức năng nào đó. Được dùng để mô tả dữ liệu di chuyển từ vị trí này đến vị trí khác. Ký hiệu: Một luồng dữ liệu được mô tả bởi một mũi tên với tên dữ liệu kèm theo, chiều của mũi tên chỉ hướng di chuyển của dữ liệu. Tên của luồng dữ liệu thể hiện trạng thái logic của thông tin chứ không phải dạng vật lý của nó. Phiếu nhập Nhập kho Thẻ kho 101 2.2. PHÂN TÍCH HỆ THỐNG VỀ CHỨC NĂNG b. Các thành phần của một DFD: Kho dữ liệu (Data store) – Tài liệu lưu trữ Về mặt vật lý, kho dữ liệu là các tập tin dữ liệu trong máy tính hoặc những tập tài liệu được lưu trữ ở văn phòng. Kho dữ liệu là các dữ liệu được lưu giữ trên giá mang nó, vì vậy người ta thường lấy tên của vật mang nó làm tên của kho dữ liệu.  Ký hiệu: Phiếu xuất Phiếu xuất Phiếu xuất 102 2.2. PHÂN TÍCH HỆ THỐNG VỀ CHỨC NĂNG b. Các thành phần của một DFD: Tiến trình (Proccess): Là một công việc hoặc một hành động có tác động lên dữ liệu làm cho chúng di chuyển, thay đổi hoặc được phân phối. Chỉ được xem là một tiến trình trong DFD nếu chúng nhận thông tin đầu vào và có thông tin đầu ra. 103 2.2. PHÂN TÍCH HỆ THỐNG VỀ CHỨC NĂNG b. Các thành phần của một DFD: Tác nhân ngoài (extenal entity): Là một cá nhân hoặc một tổ chức ở bên ngoài lĩnh vực nghiên cứu của hệ thống. Tác nhân ngoài là phần sống còn của hệ thống, bởi vì chúng là nguồn cung cấp thông tin cho hệ thống và là nguyên nhân kích hoạt hệ thống. Ví dụ: một luồng dữ liệu là “Đơn đặt hàng” đến một tác nhân ngoài là “Nhà cung cấp”. Nhà cung cấp Đơn đặt hàng 104 2.2. PHÂN TÍCH HỆ THỐNG VỀ CHỨC NĂNG b. Các thành phần của một DFD: Tác nhân ngoài (extenal entity): Là một cá nhân hoặc một tổ chức ở bên ngoài hệ thống. Tác nhân trong (intenal entity): Là một cá nhân, chức năng hoặc một hệ thống con của hệ thống. Ví dụ: một luồng dữ liệu là “Phiếu xuất/nhập” đến một tác nhân trong là “Thủ kho” Phiếu nhập/xuất Thủ kho 105 2.2. PHÂN TÍCH HỆ THỐNG VỀ CHỨC NĂNG c. Các chú ý khi xây dựng một DFD Dựa vào biểu đồ chức năng nghiệp vụ Sử dụng BFD để xác định các tiến trình theo từng mức cho DFD. Bởi vì BFD được thực hiện phân rã thành các mức nên nó dùng để chỉ ra các mức tương ứng trong DFD. Tuy nhiên để kiểm tra tính đúng đắn của các thành phần trong một DFD cần phải dựa vào các đặc trưng dưới đây. 106 2.2. PHÂN TÍCH HỆ THỐNG VỀ CHỨC NĂNG Tiến trình: Không một tiến trình nào chỉ có thông tin vào mà không có thông tin ra. Nếu một đối tượng nào đó mà chỉ có thông tin vào mà không có thông tin ra thì đó có thể là một tác nhân ngoài (đích-thu nhận thông tin). Không một tiến trình nào chỉ có thông tin ra mà không có thông tin vào. Nếu một đối tượng nào đó mà chỉ có thông tin ra mà không có thông tin vào thì đó có thể là một tác nhân trong (nguồn-phát sinh thông tin). Thông tin vào của một tiến trình phải khác với thông tin ra của tiến trình đó. Tên một tiến trình phải duy nhất và là một mệnh đề chỉ hành động. 107 2.2. PHÂN TÍCH HỆ THỐNG VỀ CHỨC NĂNG Kho dữ liệu:  Tên một kho dữ liệu phải là một mệnh đề danh từ.  Dữ liệu không thể di chuyển trực tiếp từ một kho dữ liệu này đến một kho dữ liệu khác.  Không thể di chuyển trực tiếp dữ liệu từ một tác nhân đến một kho dữ liệu.  Không thể di chuyển trực tiếp dữ liệu từ một kho dữ liệu đến một tác nhân. Tác nhân:  Tên một tác nhân phải là một mệnh đề danh từ.  Dữ liệu không thể di chuyển trực tiếp từ một tác nhân này đến một tác nhân khác. 108 2.2. PHÂN TÍCH HỆ THỐNG VỀ CHỨC NĂNG Luồng dữ liệu:  Tên một luồng dữ liệu phải là một mệnh đề danh từ.  Một luồng dữ liệu chỉ có một hướng chỉ hướng di chuyển của dữ liệu.  Một luồng dữ liệu không thể quay lui nơi nó vừa đi khỏi.  Một luồng dữ liệu đi vào một kho có nghĩa là kho được cập nhật dữ liệu.  Một luồng dữ liệu đi ra khỏi một kho có nghĩa là dữ liệu được đọc từ kho. 109 2.2. PHÂN TÍCH HỆ THỐNG VỀ CHỨC NĂNG d. Kỹ thuật phân mức trong DFD Căn cứ vào việc phân rã chức năng của một BFD: Mô tả một DFD theo nhiều mức khác nhau. Mỗi mức được thể hiện trong một hoặc nhiều trang. Mức 0: còn gọi là mức bối cảnh  Chỉ gồm một DFD, trong đó chỉ có một chức năng duy nhất (chức năng tổng quát của hệ thống) trao đổi các luồng thông tin với các tác nhân ngoài. Tên của trang mức 0 là tên của hệ thống. Mức 1: còn gọi là mức đỉnh  Chỉ gồm một DFD 110 2.2. PHÂN TÍCH HỆ THỐNG VỀ CHỨC NĂNG Các mức 2,3,4,... mỗi mức gồm nhiều DFD được thành lập như sau:  Cứ mỗi chức năng ở mức trên, ta thành lập một DFD ở mức dưới, gọi là biểu diễn DFD ở mức con.  Phân rã chức năng đó thành nhiều chức năng con  Vẽ lại các luồng dữ liệu vào và ra chức năng trên, nhưng bây giờ phải vào hoặc ra chức năng con thích hợp.  Nghiên cứu các quan hệ về dữ liệu giữa các chức năng con, nhờ đó bổ sung các luồng dữ liệu nội bộ hoặc các kho dữ liệu nội bộ.  Các chức năng được đánh số theo ký pháp chấm (.) để tiện theo dõi vệt triển khai từ trên xuống. 111 2.2. PHÂN TÍCH HỆ THỐNG VỀ CHỨC NĂNG 112 2.2. PHÂN TÍCH HỆ THỐNG VỀ CHỨC NĂNG  Tổng quát, có thể định nghĩa một cách quy nạp biểu đồ luồng dữ liệu các mức như sau: Biểu đồ luồng dữ liệu mức n là biểu đồ luồng dữ liệu nhận được từ việc phân rã một tiến trình thuộc biểu đồ luồng dữ liệu mức n-1. Như vậy biểu đồ luồng dữ liệu ở mỗi mức là tập hợp các DFD ở mức đó. 113 VÍ DỤ- Kỹ thuật phân mức 114 VÍ DỤ- Kỹ thuật phân mức Mức 0: chức năng tổng quát của HT: “Quản lý tín dụng”. Tác nhân của hệ thống: “Khách vay”. Trả lời đơn vay Khách vay Đơn vay QUẢN LÝ TÍN DỤNG Nợ hoàn trả DFD ở mức 0 (mức bối cảnh) 115 VÍ DỤ- Kỹ thuật phân mức Mức 1 Chức năng ở mức 0 được phân rã thành 2 chức năng con là “Cho vay” và “Thu nợ”. Ngoài ba luồng dữ liệu đã có ở mức 0 phải được bảo toàn, thì ta thấy luồng dữ liệu trao đổi giữa hai chức năng “Cho vay” và “Thu nợ” không trực tiếp mà phải thông qua một kho dữ liệu đó là “Sổ nợ”. Ta có DFD mức đỉnh như hình dưới đây. Trả lời đơn vay 1.Cho vay Sổ nợ Đơn vay Khách vay Nợ hoàn trả 2. Thu nợ DFD ở mức 1 (mức đỉnh) 116 VÍ DỤ- Kỹ thuật phân mức Mức 2: Chức năng “Cho vay” ở mức 1 được phân rã thành 3 chức năng con là “Nhận đơn”, “Duyệt vay” và “Trả lời đơn”; Chức năng “Thu nợ” ở mức 1 được phân rã thành 3 chức năng con là “Xác định kỳ hạn trả”, “Xử lý nợ trả trong hạn” và “Xử lý nợ trả ngoài hạn”. Để bảo toàn các luồng dữ liệu vào/ra và thêm các luồng dữ liệu nội bộ ta thành lập được hai DFD định nghĩa cho hai chức năng 1 và 2 như sau: 117 VÍ DỤ- Kỹ thuật phân mức Mức 2 Đơn đã kiểm tra Đơn vay Khách vay 1.1 Nhận đơn 1.2 Duyệt vay Đơn đã duyệt Sổ nợ Từ chối vay 1.3 Trả lời đơn Đáp ứng vay DFD ở mức 2 (định nghĩa chức năng 1: Chovay) 118 VÍ DỤ- Kỹ thuật phân mức Mức 2 Nợ trả trong hạn 2.2 Xử lý nợ trả trong hạn Nợ hoàn trả Khách vay 2.1 Xác định kỳ hạn trả Nợ trả ngoài hạn Sổ nợ 2.3 Xử lý nợ trả ngoài hạn DFD ở mức 2 (định nghĩa chức năng 2: Thu nợ) 119 2.3. MÔ HÌNH QUAN NIỆM CỦA HTTT Mô hình quan niệm của một HTTT được thiết lập từ hai mô hình liên quan đến nhau là mô hình quan niệm về dữ liệu và mô hình quan niệm về xử lý. a. Mô hình quan niệm về dữ liệu:  là sự mô tả toàn bộ dữ liệu của hệ thống, những mô tả này độc lập với các lựa chọn môi trường cài đặt  là công cụ cho phép người phân tích thể hiện dữ liệu của hệ thống ở mức quan niệm.  Mô hình có thể mô tả bằng ngôn ngữ tự nhiên hoặc bằng hình vẽ. b. Mô hình quan niệm về xử lý:  mô tả toàn bộ các quy tắc xử lý được áp dụng cho dữ liệu của hệ thống. Mô hình quan niệm cũng là cơ sở để trao đổi giữa những người phân tích thiết kế hệ thống. 120 2.3. MÔ HÌNH QUAN NIỆM CỦA HTTT 2.3.1 Mô hình quan niệm về dữ liệu Nhắc lại một số kiến thức cần thiết  Mô hình thực thể-mối quan hệ (ER)  Các tập thực thể  Các mối quan hệ giữa các tập thực thể  Các thuộc tính của các tập thực thể và các mối quan hệ: thuộc tính đơn, phức hợp, đa trị  Các loại quan hệ giữa các tập thực thể (1-1, 1-n, n-n, isa) Chiều của mối quan hệ  Mối quan hệ một chiều (đệ quy-phản xạ)  Mối quan hệ hai chiều  Mối quan hệ nhiều chiều  Bản số 121 2.3.2 Một vài nhận xét để rà soát lại mô hình ER a. Đối tượng nào có thể làm tập thực thể? Một đối tượng có thể làm tập thực thể nếu nó được tạo thành từ một lớp các cá thể tương ứng. b. Yếu tố TT gì có thể làm thuộc tính cho một tập thực thể? Các thông tin đặc trưng để xác định các thực thể trong một tập thực thể đều có thể làm thuộc tính cho tập thực thể đó. c. Loại bỏ các thuộc tính vô nghĩa Loại bỏ các thông tin không bao giờ sử dụng đến. 122 2.3.2 Một vài nhận xét để rà soát lại mô hình ER d.Tính độc lập của các thuộc tính Thuộc tính của một tập thực thể không được suy từ những thuộc tính khác của tập thực thể đó. 123 2.3.2 Một vài nhận xét để rà soát lại mô hình ER d.Tính độc lập của các thuộc tính Thuộc tính của một tập thực thể không được suy từ những thuộc tính khác của tập thực thể đó. e. Xác định thuộc tính khóa Trong mỗi tập thực thể nên chọn khóa chỉ có một thuộc tính để tiện việc xử lý. Nếu trong tập thực thể không có một thuộc tính nào để làm khóa thì nên áp đặt một thuộc tính bên ngoài để làm khóa. Thông thường thuộc tính áp đặt này có dạng: Mã + <Tên tập thực thể> 124 2.3. MÔ HÌNH QUAN NIỆM CỦA HTTT 2.3.2 Một vài nhận xét để rà soát lại mô hình ER d.Tính độc lập của các thuộc tính Thuộc tính của một tập thực thể không được suy từ những thuộc tính khác của tập thực thể đó. f. Tách thuộc tính có dung lượng lớn Nếu một thuộc tính của tập thực thể có nhiều giá trị, mỗi giá trị chiếm một dung lượng lớn và lặp lại nhiều lần thì nên tách thành một tập thực thể riêng có tên là <tên thuộc tính> và có hai thuộc tính là:  Mã + <tên thuộc tính>  Tên + <tên thuộc tính> 125 2.3.2 Một vài nhận xét để rà soát lại mô hình ER g. Xử lý một thuộc tính lặp nằm trong một tập thực thể Nếu trong tập thực thể có thuộc tính lặp (đa trị) thì tách thuộc tính này thành một tập thực thể có tên: <tên thuộc tính đa trị> và có hai thuộc tính là: • Mã + <tên thuộc tính> và • Tên + <tên thuộc tính> Ví dụ: một nhân viên có thể có nhiều sđt 126 2.3.2 Một vài nhận xét để rà soát lại mô hình ER h. Xử lý 1 nhóm thuộc tính lặp nằm trong 1 tập th.thể Nếu trong một tập thực thể có một nhóm thuộc tính lặp thì tách chúng (các thuộc tính lặp) thành một tập thực thể riêng. Tập thực thể này nhận các thuộc tính lặp làm thuộc tính và nhận thuộc tính khóa của tập thực thể gốc làm khóa. Ví dụ: 127 2.3.2 Một vài nhận xét để rà soát lại mô hình ER h. Các tập thực thể có mối quan hệ ISA  Khi một thuộc tính của tập thực thể mà chỉ có một số phần tử có giá trị, nếu phần tử nào có giá trị thì có thêm một số thuộc tính riêng của nó thì chuyển thành một tập thực thể riêng có tên là <tên thuộc tính> và có thuộc tính là các thuộc tính riêng của nó. Tập thực thể gốc gọi là tập thực thể Cha, tập thực thể được tách ra gọi là tập thực thể Con.  Ví dụ 128 2.3.3 Cách mô tả mô hình quan niệm về dữ liệu Mô hình quan niệm dữ liệu là mô hình liên hoàn các tập thực thể và mối quan hệ của hệ thống. Để mô tả mô hình quan niệm về dữ liệu của một HTTT, cần mô tả thông tin theo các bước sau: B1: Mô tả toàn bộ các tập thực thể và các thuộc tính tương ứng của chúng. B2: Mô tả toàn bộ các mối quan hệ. Ý nghĩa của mỗi mối quan hệ và các thuộc tính tương ứng của chúng (nếu có). Bản số của mỗi tập thực thể qua mối quan hệ. Loại mối quan hệ: một chiều, hai chiều (1-1, 1-n, n-n, isa,...), nhiều chiều. 129 B3: Vẽ mô hình thực thể - mối quan hệ. 2.3.4 Mô hình quan niệm về xử lý a. Mục đích: Mô hình quan niệm xử lý nghiên cứu mặt động của hệ thống thông tin, nhằm xác định hệ thống gồm những chức năng gì, các chức năng đó liên hệ với nhau như thế nào? b. Một số thuật ngữ và khái niệm a. Biến cố (event): một sự việc gây ra sự thay đổi trạng thái của hệ thống. Một biến cố có thể xuất hiện bên trong hay bên ngoài hệ thống, tạo phản ứng cho hệ thống thông qua một qui tắc quản lý nào đó. 130 2.3.4 Mô hình quan niệm về xử lý Phân loại biến cố :  Biến cố vào: biến cố tham gia vào việc kích hoạt một công việc nào đó của hệ thống.  Biến cố ra: biến cố được sinh ra sau khi thực hiện một hoặc nhiều công việc của hệ thống.  Biến cố trong: biến cố xảy ra bên trong hệ thống để các hệ thống con trao đổi thông tin cho nhau.  Biến cố ngoài: biến cố đến từ môi trường bên ngoài hệ thống.  Biến cố thời gian: biến cố gắn liền với thời gian, có tính chu kỳ. 131 2.3.4 Mô hình quan niệm về xử lý b. Công việc:  Là một xử lý nhỏ nhất mà hệ thống thực hiện khi một biến cố trong hệ thống xuất hiện.  Thông thường một công việc chưa đủ để xác định được một chức năng hoặc một nhiệm vụ của hệ thống.  Ví dụ, công việc "Kiểm tra hàng nhập về" chưa đủ điều kiện để thực hiện nhiệm vụ "nhập kho", bởi vì nhiệm vụ này chỉ được hoàn tất sau khi các công việc kiểm tra và làm phiếu nhập được thực hiện xong.  Sau khi một công việc được thực hiện thì thông thường một trong hai trạng thái sẽ xảy ra: thành công (OK) và không thành công (⌐OK). Hai trạng 132 thái này sẽ kèm theo các biến cố ra tương ứng. 2.3.4 Mô hình quan niệm về xử lý c. Điểm đợi Thời điểm để đợi các biến cố xảy ra thì công việc mới thực hiện được gọi là điểm đợi. Các biến cố này kích hoạt công việc theo hai chế độ: Chế độ AND: khi tất cả các biến cố tại điểm đợi cùng xảy ra thì công việc mới được thực hiện. Chế độ OR: khi một trong các biến cố tại điểm đợi xảy ra thì công việc mới được thực hiện. Ví dụ: Biến cố "sách đã cho mượn" được thực hiện bởi công việc "CHO MƯỢN SÁCH" nếu tại điểm đợi các biến cố xảy ra: [(Độc giả yêu cầu)(Đủ tư cách độc giả)(có lệnh của GĐ)] (có sách) 133 2.3.4 Mô hình quan niệm về xử lý Mô tả một công việc, biến cố, điểm đợi 134 2.3.4 Mô hình quan niệm về xử lý Chức năng của một hệ thống thông tin được mô tả một cách tổng quát như sau: 135 2.3.4 Mô hình quan niệm về xử lý Ví dụ, trong hệ thống thông tin “Quản lý kho hàng” Chức năng “Bán hàng” sẽ bao gồm các công việc: kiểm tra tư cách khách hàng, kiểm tra hàng tồn kho, viết phiếu xuất, thanh toán, xuất kho. 136 2.3.4 Mô hình quan niệm về xử lý 137 2.4. MÔ HÌNH TỔ CHỨC CỦA HTTT 2.4.1. Khái niệm: Mô hình tổ chức được thiết lập từ hai mô hình: a. Mô hình tổ chức về dữ liệu: Mô hình này được hình thành do sự chuyển đổi các tập thực thể và các mối quan hệ trong mô hình ER. Ở mức tổ chức thông tin được mô tả theo giải pháp cơ sở dữ liệu và thực chất chính là quan hệ logic của chúng, nên mức tổ chức còn được gọi mức logic. b. Mô hình tổ chức về xử lý: Mô tả về mặt tổ chức của các xử lý. Mô hình này trả lời cho các câu hỏi: Ai?, Khi nào?, Ở đâu?, Như thế 138 nào? 2.4. MÔ HÌNH TỔ CHỨC CỦA HTTT Nhắc lại một số kiến thức về CSDL quan hệ  Cơ sở khoa học – Nền tảng - Lịch sử  Quan hệ  Lược đồ quan hệ  Phụ thuộc hàm  Phép tách: Bảo toàn thông tin Bảo toàn phụ thuộc hàm  Lý thuyết chuẩn hóa: 1NF, 2NF, 3NF, BCNF 139 2.4.2. Mô hình tổ chức dữ liệu Các quy tắc chuyển đổi từ mô hình ER sang mô hình dữ liệu quan hệ a. Chuyển một tập thực thể thành quan hệ Quy tắc 1: Mỗi tập thực thể trong mô hình quan niệm dữ liệu được chuyển thành một quan hệ: có tên là tên của tập thực thể; có thuộc tính và khóa là thuộc tính và khóa của tập thực thể và có thể có thêm thuộc tính là khóa ngoại nếu có. Nhân viên -Mã NV -Họ tên -Ngày sinh -Mã đơn vị Chuyển thành Nhân viên (Mã NV , Họ tên, Ngày sinh, Mã đơn vị) 140 2.4.2. Mô hình tổ chức dữ liệu Quy tắc 2: Tập thực thể tham gia vào mối quan hệ hai ngôi có cặp bản số (1,1) ----- (1,n) thì quan hệ sinh ra bởi tập thực thể ở nhánh (1,1) sẽ nhận khóa của tập thực thể ở nhánh (1,n) làm khóa ngoại Nhân viên -Mã NV -Họ Tên -Ngày Sinh (1,1) Thuộc (1,n) Đơn vị -Mã đơn vị -Tên đơn vị Chuyển thành Nhân viên (Mã NV , Họ Tên, Ngày Sinh, Mã đơn vị) Đơn vị (Mã đơn vị, Tên đơn vị) 2.4.2. Mô hình tổ chức dữ liệu Quy tắc 3: Chuyển tập thực thể trong mối quan hệ ISA  Tập thực thể con trong mối quan hệ ISA của mô hình quan niệm dữ liệu được chuyển thành một quan hệ, với tên là tên của tập thực thể con, có các thuộc tính là thuộc tính của tập thực thể con và nhận khóa của tập thực thể cha làm khóa. Trường hợp xảy ra quan hệ ISA trong một quan hệ ISA thì lược đồ quan hệ sinh ra từ tập thực thể "cháu" nhận thuộc tính khóa của tập thực thể "Ông" làm thuộc tính khóa. 2.4.2. Mô hình tổ chức dữ liệu Quy tắc 3: Chuyển tập thực thể trong mối quan hệ ISA Ví dụ: Bộ đội -Ngày NN -Ngày XN n is a 1 Nhân viên -Mã NV -Họ NV -Tên NV -Ngày sinh 1 is a n Đảng viên -Ngày VĐ -Ngày CT Chuyển thành Đảng viên Bộ đội Nhân viên (Mã NV,Ngày VĐ, Ngày CT) (Mã NV,Ngày NN, Ngày XN) (Mã NV,Họ NV, Tên NV, Ngày sinh) 2.4.2. Mô hình tổ chức dữ liệu a. Chuyển một mối quan hệ thành quan hệ Quy tắc 4: i. Mối quan hệ hai ngôi không có thuộc tính riêng, có cặp bản số (1,1) ---- (1,n) thì không chuyển thành một quan hệ. Huyện -Mã huyện -Tên huyện (1,1) H-T (1,n) Tỉnh -Mã tỉnh -Tên tỉnh Chuyển thành Huyện (Mã huyện, Tên huyện, Mã tỉnh) Tỉnh (Mã tỉnh,Tên tỉnh) 2.4.2. Mô hình tổ chức dữ liệu Quy tắc 4: ii. Mối quan hệ hai ngôi có thuộc tính riêng, có cặp bản số (1,1) ---- (1,n) thì chuyển thành một quan hệ, có tên là tên của mối quan hệ, có thuộc tính là thuộc tính của mối quan hệ và có khoá là khoá của các tập thực thể tham gia vào mối quan hệ. Cán bộ -Mã CB -Tên CB -HSL (1,1) Thuộc - Năm (1,n) chuyển thành Cán bộ Đơn vị Thuộc (Mã CB, Tên CB, HSL) (Mã ĐV, Tên ĐV) (Mã CB, Mã ĐV, Năm) Đơn vị -Mã ĐV -Tên ĐV 2.4.2. Mô hình tổ chức dữ liệu Quy tắc 5: Mối quan hệ hai ngôi có cặp bản số (1,n) ---- (1,n) hay mối quan hệ nhiều hơn hai ngôi (không phân biệt bản số) được chuyển thành một quan hệ: có tên là tên của mối quan hệ có khóa là khóa của tất cả các tập thực thể tham gia vào mối quan hệ có thuộc tính là các thuộc tính riêng của nó (nếu có). 2.4.2. Mô hình tổ chức dữ liệu Quy tắc 5: Mối quan hệ hai ngôi có cặp bản số (1,n) ---- (1,n) hay mối quan hệ nhiều hơn hai ngôi (không phân biệt bản số) được chuyển thành một quan hệ: có tên là tên của mối quan hệ có khóa là khóa của tất cả các tập thực thể tham gia vào mối quan hệ có thuộc tính là các thuộc tính riêng của nó (nếu có). 2.4.2. Mô hình tổ chức dữ liệu Định nghĩa Mô hình tổ chức dữ liệu, còn gọi là mô hình cơ sở dữ liệu, là toàn bộ các quan hệ của bài toán được chuyển đổi từ mô hình quan niệm dữ liệu theo các quy tắc chuyển đổi trên. Ví dụ: Mô hình tổ chức dữ liệu của HTTT “Quản lý kho hàng” 2.4.2. Mô hình tổ chức dữ liệu 2.4.2. Mô hình tổ chức dữ liệu Mô tả dưới dạng bảng 2.4.2. Mô hình tổ chức dữ liệu Nhắc lại các dạng chuẩn a. Mục đích của chuẩn hóa Chuẩn hóa dữ liệu là một quá trình chuyển một cấu trúc dữ liệu phức hợp thành các cấu trúc dữ liệu đơn giản, rõ ràng và nhằm các mục đích sau: Tối ưu hóa lưu trữ Tránh dư thừa dữ liệu Thông tin nhất quán Đảm bảo các phụ thuộc dữ liệu theo đúng mô hình mà vẫn không làm tổn thất thông tin. Nhắc lại các dạng chuẩn •Dạng chuẩn 1 (1NF) Một lược đồ quan hệ được gọi là ở dạng chuẩn 1 nếu mọi thuộc tính của nó là thuộc tính đơn (các thuộc tính không có nhu cầu phân rã trong các xử lý). Ví dụ: lược đồ quan hệ dưới đây không phải ở 1NF: SINHVIEN(MSSV, HTEN, QQUAN, SOTHICH) •Dạng chuẩn 2 (2NF) Một lược đồ quan hệ được gọi là ở dạng chuẩn 2 nếu nó là dạng chuẩn 1 và mọi thuộc tính không khoá phải phụ thuộc hàm đầy đủ vào khoá chính. Ví dụ: lược đồ quan hệ R(ABCD) với tập phụ thuộc hàm F={AB  C, B  D, C  D} không phải ở 2NF vì D không phụ thuộc hàm đầy đủ vào khóa. Nhắc lại các dạng chuẩn •Dạng chuẩn 3 (1NF) Phụ thuộc hàm bắc cầu: cho lược đồ quan hệ R và tập phụ thuộc hàm F xác định trên R; X, Y R, AR. Nếu ta có: X  Y , Y X, Y A và AXY thì ta nói A phụ thuộc hàm bắc cầu vào X. A được gọi là thuộc tính phụ thuộc bắc cầu, Y là các thuộc tính cầu. Định nghĩa 1: Lược đồ quan hệ R với tập phụ thuộc hàm F xác định trên R được gọi là ở 3NF nếu nó là 2NF và không tồn tại thuộc tính không khoá phụ thuộc hàm bắc cầu vào khoá. Định nghĩa 2: Lược đồ quan hệ R với tập phụ thuộc hàm F xác định trên R được gọi là ở 3NF nếu mọi phụ thuộc hàm XA đúng trong R, AX thì X phải là siêu 2.4.3. Chuẩn hoá và kiểm tra lại mô hình ER a. Trường hợp LĐQH chưa là 1NF: Khi một LĐQH chưa là 1NF thì nó có chứa thuộc tính lặp hoặc thuộc tính phức hợp. Nếu lược đồ có thuộc tính lặp thì ta tách thành hai lược đồ con: LĐ quan hệ 1: gồm các thuộc tính lặp và khoá chính xác định chúng. LĐ quan hệ 2: gồm các thuộc tính còn lại (đơn) và khoá chính. Ví dụ 2.4.3. Chuẩn hoá và kiểm tra lại mô hình ER 1NF 0NF SỐPHIẾUXUẤT NGÀY NGƯỜI MUA ĐẠILÝ SỐCMND ĐỊACHỈ MỤCĐÍCH TÊNHÀNG (lặp) MÃHÀNG (lặp) ĐƠNVỊ (lặp) ĐƠNGIÁ (lặp) SỐLƯỢNG (lặp) SỐPHIẾUXUẤT NGÀY NGƯỜI MUA ĐẠILÝ SỐCMND ĐỊACHỈ MỤCĐÍCH 1NF SỐPHIẾUXUẤT TÊNHÀNG MÃHÀNG ĐƠNVỊ ĐƠNGIÁ SỐLƯỢNG 156 2.4.3. Chuẩn hoá và kiểm tra lại mô hình ER a. Trường hợp LĐQH chưa là 2NF: Khi một LĐQH là 1NF nhưng không là 2NF thì trong quan hệ sẽ tồn tại thuộc tính không khoá phụ thuộc vào một bộ phận của khoá chính. Khi đó ta tách thành hai lược đồ quan hệ con: LĐ quan hệ 1: gồm các thuộc tính phụ thuộc không đầy đủ vào khoá chính và phần khoá bị phụ thuộc. LĐ quan hệ 2: gồm các thuộc tính còn lại và khoá chính Ví dụ 2.4.3. Chuẩn hoá và kiểm tra lại mô hình ER 2NF 1NF SỐPHIẾUXUẤT NGÀY NGƯỜI MUA ĐẠILÝ SỐCMND ĐỊACHỈ MỤCĐÍCH 1NF SỐPHIẾUXUẤT TÊNHÀNG MẪHÀNG ĐƠNVỊ ĐƠNGIÁ SỐLƯỢNG SỐPHIẾUXUẤT NGÀY NGƯỜI MUA ĐẠILÝ SỐCMND ĐỊACHỈ MỤCĐÍCH 2NF SỐPHIẾUXUẤT MẪHÀNG SỐLƯỢNG 2NF MẪHÀNG TÊNHÀNG ĐƠNVỊ ĐƠNGIÁ 158 2.4.3. Chuẩn hoá và kiểm tra lại mô hình ER a. Trường hợp LĐQH chưa là 3NF: Khi một quan hệ là 2NF nhưng không là 3NF thì sẽ tồn tại phụ thuộc hàm bắc cầu trong quan hệ. Khi đó ta tách thành hai lược đồ quan hệ con: LĐ quan hệ 1: gồm các thuộc tính phụ thuộc bắc cầu và thuộc tính cầu. LĐ quan hệ 2: gồm các thuộc tính còn lại và thuộc tính cầu. Ví dụ 3NF 2NF SỐPHIẾUXUẤT NGÀY NGƯỜI MUA ĐẠILÝ SỐCMND ĐỊACHỈ MỤCĐÍCH 2NF SỐPHIẾUXUẤT MẪHÀNG SỐLƯỢNG 2NF MẪHÀNG TÊNHÀNG ĐƠNVỊ ĐƠNGIÁ SỐPHIẾUXUẤT NGÀY SỐCMND MỤCĐÍCH 3NF NGƯỜI MUA ĐẠILÝ SỐCMND ĐỊACHỈ 3NF SỐPHIẾUXUẤT MẪHÀNG SỐLƯỢNG 3NF MẪHÀNG TÊNHÀNG ĐƠNVỊ ĐƠNGIÁ 160 Quá trình chuẩn hoá có thể mô tả bằng sơ đồ dưới đây. Quan hệ với các thuộc tính lặp Tách các thuộc tính lặp Chuẩn hoá thành 1NF Tách các phụ thuộc hàm bộ phận Chuẩn hoá thành 2NF Tách các phụ thuộc hàm bắc cầu Chuẩn hoá thành 3NF 161 Ví dụ: chuẩn hóa một chứng từ nhập trong HTTT “Quản lý kho hàng” 3NF Ví0NF dụ: chuẩn hóa một 1NF chứng từ nhập trong2NF HTTT “Quản lý kho hàng” SỐPHIẾUNHẬP MÃSỐ_NCC TÊN_NCC ĐỊACHỈ_NCC NGÀY TÊNHÀNG (lặp) MẪHÀNG (lặp) ĐƠNVỊTÍNH (lặp) ĐƠNGIÁ (lặp) SỐLƯỢNG (lặp) SỐPHIẾUNHẬP MÃSỐ_NCC TÊN_NCC ĐỊACHỈ_NCC NGÀY 1NF SỐPHIẾUNHẬP TÊNHÀNG MẪHÀNG ĐƠNVỊTÍNH ĐƠNGIÁ SỐLƯỢNG Chuẩn hóa chứng từ nhập SỐPHIẾUNHẬP MÃSỐ_NCC TÊN_NCC ĐỊACHỈ_NCC NGÀY 2NF SỐPHIẾUNHẬP MẪHÀNG SỐLƯỢNG 2NF MẪHÀNG TÊNHÀNG ĐƠNVỊTÍNH ĐƠNGIÁ SỐPHIẾUNHẬP MÃSỐ_NCC NGÀY 3NF MÃSỐ_NCC TÊN_NCC ĐỊACHỈ_NCC 3NF SỐPHIẾUNHẬP MẪHÀNG SỐLƯỢNG 3NF MẪHÀNG TÊNHÀNG ĐƠNVỊTÍNH ĐƠNGIÁ 163 Chuyển sang mô hình dữ liệu quan hệ 164 2.4.4. Mô hình tổ chức về xử lý Mục đích: Mô hình tổ chức về xử lý nhằm xác định rõ các công việc do ai làm, làm ở đâu, làm khi nào, làm theo phương thức nào? Các khái niệm a. Nơi làm việc: • một hệ thống thông tin quản lý được chia thành nhiều bộ phận, mỗi bộ phận được gọi là một nơi làm việc. • Nơi làm việc bao gồm: vị trí, con người, trang thiết bị tại nơi làm việc. b. Phương thức xử lý: là cách thức thực hiện công việc. Mỗi công việc có thể được thực hiện bởi một trong ba phương thức xử lý: • Xử lý thủ công: do con người trực tiếp thao tác trên đối tượng. • Xử lý tự động • Xử lý tương tác người -máy 2.4.4. Mô hình tổ chức về xử lý c. Biến cố ở mức tổ chức: là biến cố của hệ thống nhưng được đặt ở nơi phát sinh ra nó hay là nơi nhận biết nó. Ở mức tổ chức, một biến cố còn phải quan tâm: • Thời gian phản ứng: là thời gian tối đa được chờ đợi từ khi biến cố xuất hiện cho đến khi công việc được kích hoạt. • Tần suất: số lần xuất hiện lại biến cố trong một đơn vị thời gian. • Chu kỳ: là khoảng thời gian mà biến cố sẽ xuất hiện trở lại 2.4.4. Mô hình tổ chức về xử lý d. Bảng công việc Ở mức tổ chức công việc phải được xác định rõ: nơi làm việc, phương thức làm việc, tần suất và chu kỳ của nó. Các đặc trưng này được thể hiện trong bảng công việc sau đây: 2.5. MÔ HÌNH VẬT LÝ Mô hình vật lý sẽ là thể hiện cụ thể trên máy tính cho giải pháp dữ liệu đã được lựa chọn. Nó được thể hiện ở hai khía cạnh: cấu trúc dữ liệu cụ thể và phương thức truy nhập. Cũng như các mô hình đã khảo sát ở trước, mô hình vật lý được mô tả qua mô hình vật lý về dữ liệu và mô hình vật lý về xử lý. Thiết kế cơ sở dữ liệu vật lý là quá trình ánh xạ cấu trúc dữ liệu logic được xây dựng ở mô hình tổ chức dữ liệu vào mô hình bên trong hệ thống. 2.5. MÔ HÌNH VẬT LÝ 2.5.1. Mô hình vật lý về dữ liệu Thiết kế cơ sở dữ liệu vật lý Đa số các hệ thống thông tin hiện nay đều sử dụng một hệ quản trị cơ sở dữ liệu nào đó để tạo ra cơ sở dữ liệu cho hệ thống. Thiết kế cơ sở dữ liệu vật lý bao gồm các bước sau: Thiết kế cơ sở dữ liệu: mô tả các file dữ liệu, file chỉ mục,... sẽ được truy cập trong bộ nhớ máy tính như thế nào. Thiết kế hệ thống và cấu trúc chương trình: mô tả các chương trình và các mô đun chương trình khác nhau tương ứng với sơ đồ luồng dữ liệu và những yêu cầu đặt ra trong các bước phân tích trước. 2.5.1. Mô hình vật lý về dữ liệu Thiết kế cơ sở dữ liệu a. Thiết kế các trường Các yêu cầu về việc thiết kế các trường Tiết kiệm không gian nhớ Biểu diễn được mọi giá trị có thể Cài đặt các ràng buộc toàn vẹn của dữ liệu Đặt giá trị mặc định (Default) để giảm thiểu thời gian nhập dữ liệu Chọn kiểu dữ liệu và độ rộng của trường Khai báo độ rộng vừa đủ Chọn đúng kiểu dữ liệu Không làm phức tạp cấu trúc dữ liệu của hệ thống. 2.5.1. Mô hình vật lý về dữ liệu a. Thiết kế các trường Các yêu cầu về việc thiết kế các trường Tiết kiệm không gian nhớ Biểu diễn được mọi giá trị có thể Cài đặt các ràng buộc toàn vẹn của dữ liệu Đặt giá trị mặc định (Default) để giảm thiểu thời gian nhập dữ liệu Chọn kiểu dữ liệu và độ rộng của trường Khai báo độ rộng vừa đủ Chọn đúng kiểu dữ liệu Không làm phức tạp cấu trúc dữ liệu của hệ thống. 2.5.1. Mô hình vật lý về dữ liệu b. Thiết kế các file File giao dịch ( transaction file): là file dữ liệu tạm thời phục vụ cho các hoạt động hằng ngày của tổ chức. File này thường được thiết kế để phục vụ việc xử lý nhanh các tình huống có thể xảy ra. File làm việc (work file): file tạm thời để lưu kết quả trung gian, file này tự động xoá đi khi không cần thiết. File bảo vệ (protection file): file được thiết kế để lưu trữ các file khác nhau có nguy cơ bị sai hỏng trong quá trình làm việc. File lịch sử (history file): file chứa những dữ liệu cũ hiện không sử dụng, nhưng có thể sử dụng để làm một việc gì đó khi cần thiết. 2.5.1. Mô hình vật lý về dữ liệu c. Một ví dụ về thiết kế file dữ liệu Trong hệ thống thông tin “Quản lý kho hàng ” chúng ta đã có mô hình tổ chức dữ liệu của hệ thống là các quan hệ sau: c. Một ví dụ về thiết kế file dữ liệu c. Một ví dụ về thiết kế file dữ liệu c. Một ví dụ về thiết kế file dữ liệu 2.5.2. Mô hình vật lý về xử lý a. Mục đích: Trả lời cho câu hỏi cuối cùng là: các công việc hoạt động như thế nào? Từ mô hình tổ chức xử lý đã có, người phân tích sẽ tiến hành xem xét, biến các chức năng, công việc thành các đơn vị chương trình. Ứng với mỗi đơn vị chương trình này người phân tích phải viết một đặc tả chi tiết để chuẩn bị cho việc lập trình. 2.5.2. Mô hình vật lý về xử lý b. Mô đun xử lý Mô đun xử lý là thể hiện các công việc có liên quan với nhau và được thực hiện liền mạch nhằm thực hiện một chức năng nào đó. Thông thường một mô đun xử lý thể hiện một công việc có bản chất là cập nhật hoặc tra cứu dữ liệu và thao tác trên một nhóm dữ liệu nhỏ. Ví dụ, Chức năng làm phiếu xuất kho sẽ bao gồm các mô đun sau: Tra cứu danh sách các đại lý để kiểm tra khách hàng Kiểm tra hàng tồn kho Lấy yêu cầu để lập phiếu xuất và cập nhật tồn kho 2.5.2. Mô hình vật lý về xử lý ... c. Phân rã mô đun Mục đích: Để dễ dàng trong việc mã hoá, cài đặt chương trình và sửa chữa Phân rã mô đun nhỏ đến một mức nào đó có thể xuất hiện các mô đun chung, điều này sẽ giảm nhẹ công sức lập trình sau này Phân rã mô đun cũng gợi ra giao diện chọn chức năng theo kiểu thực đơn trong chương trình tổng thể 2.5.2. Mô hình vật lý về xử lý d. Sơ đồ phân rã chức năng Một mô đun có thể phân rã thành nhiều mô đun con. Mô đun con không thể phân rã thêm được nữa được gọi là mô đun sơ cấp. Việc phân rã này phải bảo đảm mối liên hệ giữa mô đun lớn với các mô đun con... Dùng sơ đồ phân rã chức năng để mô tả việc phân rã: 2.5.2. Mô hình vật lý về xử lý d. Sơ đồ tổng thể phân rã chức năng Dựa trên kết quả phân rã mô đun, người phân tích phải lên một sơ đồ tổng thể các chức năng để hướng đến cấu trúc hoá chương trình. Hiện nay có một vài quan điểm về việc gộp các mô đun thành từng nhóm chức năng trong chương trình. Gộp các mô đun theo hướng đối tượng: nhóm các chức năng theo dữ liệu hoặc theo tập thực thể Gộp các mô đun theo hướng chức năng: Gộp theo sự kiện là gộp theo hoạt động của hệ thống Gộp các mô đun theo sự tiện lợi: gộp các mô đun theo tiêu chuẩn tiện dụng hoặc theo người sử dụng cụ thể hoặc theo mạch công việc Gộp các mô đun theo hướng đối tượng: ĐÀO TẠO SINH VIÊN CẬP NHẬT LÝ LỊCH SINH VIÊN CẬP NHẬT ĐIỂM THI THÔNG KÊ KẾT QUẢ HỌC TẬP GIÁO VIÊN CẬP NHẬT LÝ LỊCH GIÁO VIÊN GHI NHẬN KHỐI LƯỢNG GDẠY THÔNG KÊ GIẢNG DẠY MÔN HỌC CẬP NHẬP MÔN HỌC LẬP CHƯƠNG TRÌNH ĐÀO TẠO PHÂN CÔNG GIẢNG DẠY Gộp các chức năng theo đối tượng Gộp các mô đun theo hướng chức năng: QUẢN LÝ KHO NHẬP HÀNG CẬP NHẬT SỐ LIỆU, CẬP NHẬT PHIẾU NHẬP, CẬP NHẬT TỒN KHO IN PHIẾU NHẬP XUẤT HÀNG CẬP NHẬT SỐ LIỆU, CẬP NHẬT PHIẾU XUẤT, CẬP NHẬT TỒN KHO IN PHIẾU XUẤT BÁO CÁO BÁO CÁO TỒN KHO CÂN ĐỐI KHO Gộp các chức năng theo hướng chức năng Gộp các mô đun theo mạch công việc Gộp các chức năng theo mạch công việc 2.5.2. Mô hình vật lý về xử lý e. Mô tả các mô đun Sau khi phân rã các mô đun, người phân tích phải chuyển giao các kết quả phân tích thiết kế cho người lập trình để chuẩn bị cài đặt. Các mô đun này phải được mô tả một cách chi tiết thông qua các biểu đồ được gọi là IPO Chart như sau: 2.5.2. Mô hình vật lý về xử lý e. Mô tả các mô đun 2.6. THIẾT KẾ GIAO DIỆN CỦA HỆ THỐNG 2.6.1. Mục đích Thiết kế môi trường giao tiếp giữa người sử dụng và hệ thống, thoả mãn điều kiện: Dễ sử dụng: Giao diện dễ sử dụng ngay cả với những người không có kinh nghiệm. Dễ học: Các chức năng gần gũi với tư duy của người sử dụng để họ có thể nắm bắt dễ dàng nhanh chóng. Tốc độ thao tác: Giao diện không đòi hỏi các thao tác phức tạp hay dài dòng, hỗ trợ các phím tắt, phím nóng. Dễ phát triển: Giao diện được xây dựng dễ dàng, sẵn sàng đáp ứng các yêu cầu thay đổi của người sử dụng. 2.6. THIẾT KẾ GIAO DIỆN CỦA HỆ THỐNG 2.6.2. Các loại giao diện Hộp hội thoại: Là các giao diện phục vụ cho việc kiểm soát hệ thống, trao đổi thông tin giữa người sử dụng và hệ thống, kiểm tra quyền truy nhập (Tên, mật khẩu), các hướng dẫn sử dụng hệ thống, các thông báo lỗi sử dụng hay lỗi hệ thống nếu có... Màn hình nhập dữ liệu: là các khung nhập liệu cho phép người sử dụng tiến hành nhập dữ liệu cho hệ thống hay cung cấp thông tin cho việc tìm kiếm dữ liệu, đưa ra các báo cáo theo yêu cầu. Màn hình báo cáo: là các biểu mẫu hiển thị các thông tin được thu thập và tổng hợp theo yêu cầu của người sử dụng. 2.6. THIẾT KẾ GIAO DIỆN CỦA HỆ THỐNG 2.6.3. Các nguyên tắc chung khi thiết kế giao diện Thông tin phản hồi: Luôn cung cấp thông tin phản hồi về công việc đang tiến hành. Thông tin trạng thái: cung cấp cho người sử dụng thông tin về trạng thái của hệ thống. Công việc tối thiểu: Hạn chế tối đa sự cố gắng không cần thiết của người sử dụng. Trợ giúp: Sẵn sàng cung cấp các trợ giúp khi người sử dụng cần. Dễ dàng thoát ra: Cho phép người sử dụng thoát ra khỏi hộp thoại dễ dàng bằng các thao tác quen thuộc. Làm lại: Cho phép huỷ bỏ các thao tác đã tiến hành, tăng khả năng thứ lỗi của chương trình. 2.7. THIẾT KẾ BÁO BIỂU Hình thức tài liệu xuất: Đĩa, màn hình, giấy in,.. Dạng tài liệu xuất Có cấu trúc: Bảng biểu, phiếu Không có cấu trúc: Trả lời theo nhu cầu Yêu cầu đối với tài liệu xuất Đầy đủ, chính xác Dễ hiểu, dễ đọc Kích thước tài liệu phải phù hợp, các mục phải bố trí hợp lý. được người sử dụng đồng ý 2.7. THIẾT KẾ BÁO BIỂU Các hình thức xuất tài liệu Khung in sẵn Không có khung in sẵn Cách trình bày một tài liệu: gồm 3 phần Phần đầu: Các tiêu đề Phần thân: Chứa nội dung cơ bản thường được gom thành nhóm và có mối liên hệ logic với nhau Phần cuối: ngày tháng, các chữ ký nếu có Có hai loại đưa ra Đơn chiếc Tập thể 2.8. THIẾT KẾ AN TOÀN HỆ THỐNG 2.7.1 Thiết kế kiểm soát: Mục đích: nhằm hạn chế các lỗi sau:  Lỗi từ các thông tin thu thập  Lỗi do các sự cố kỹ thuật gây ra  Sự thâm nhập trái phép của người trong và ngoài hệ thống.  Rủi ro về môi trường như: cháy, bão lụt,...  Đề xuất các biện pháp nhằm đảm bảo:  Tính chính xác  Tính an toàn  Tính riêng tư 2.8. THIẾT KẾ AN TOÀN HỆ THỐNG 2.7.2 Kiểm soát các xâm phạm từ phía con người a. Xác định những điểm hở của hệ thống: Điểm hở của hệ thống là điểm mà tại đó thông tin của hệ thống có khả năng bị truy cập trái phép, bị sửa đổi, lấy cắp, thậm chí phá huỷ thông tin, có thể gây thiệt hại lớn cho cơ quan chủ quản hệ thống. Trong một hệ thống các điểm hở có thể là: Luồng dữ liệu đi và đến tác nhân của hệ thống Luồng dữ liệu cắt ngang giữa phần thực hiện bằng máy tính và phần thực hiện thủ công. Các kho dữ liệu hoặc các tệp. Các đường truyền trên mạng (đối với hệ phân tán), ... 2.8. THIẾT KẾ AN TOÀN HỆ THỐNG b. Các biện pháp phòng ngừa, khắc phục: Bảo mật vật lý: khoá, chuông báo động Nhận dạng nhân sự Mật khẩu Tạo mật mã: mã hoá dữ liệu sang dạng mã không hiểu được. Người hiểu được phải có quy tắc giải mã. Bảo mật bằng gọi lại: sự truy nhập thực hiện một cách gián tiếp, qua một trạm kiểm soát, tương tự như gọi điện thoại qua tổng đài, OTP. Phân biệt riêng tư Gán cho mỗi loại người dùng một số quyền truy nhập nhất định. Cho phép một số người dùng được phép uỷ quyền tức giao quyền truy nhập cho người khác. HẾT CHƯƠNG 2 195 CHƯƠNG 3 PHÂN TÍCH VÀ THIẾT KẾ HTTT THEO HƯỚNG ĐỐI TƯỢNG ANALYSIS AND DESIGN INFORMATION SYSTEMS IN OBJECT ORIENTED PGS.TS. Nguyễn Mậu Hân Khoa CNTT-ĐHKH HUẾ nmhan2005@yahoo.com 196 NỘI DUNG 3.1 QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG 3.2. PHÂN TÍCH YÊU CẦU HỆ THỐNG 3.3. ĐẶC TẢ CÁC YÊU CẦU CỦA HT 3.4. THIẾT KẾ HƯỚNG ĐỐI TƯỢNG 3.5. CÁC NHÓM MẪU THIẾT KẾ 3.6. THIẾT KẾ GIAO DIỆN, BÁO BIỂU, AN TOÀN HỆ THỐNG 3.1 QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM HĐT Nhận xét: Quá trình xây dựng một sản phẩm phần mềm hoặc nâng cấp một sản phẩm đã có được gọi là quá trình phát triển phần mềm (Software Development Process). Quá trình phát triển một phần mềm là quá trình xác định:  làm cái gì (WHAT?),  làm ở đâu (WHERE?)  làm khi nào (WHEN?)  làm như thế nào (HOW?). 198 3.1 QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM HĐT Có 5 bước chính cần thực hiện trong quá trình phát triển phần mềm theo hướng đối tượng: 1. Nghiên cứu hiện trạng và xác định các yêu cầu 2. Phân tích hệ thống 3. Thiết kế hệ thống 4. Lập trình và kiểm thử hệ thống 5. Vận hành và bảo trì hệ thống. 199 3.1. QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM HĐT ... 3.1.1 Nghiên cứu hiện trạng và xác định các yêu cầu Từ các yêu cầu của khách hàng chúng ta xác định được mục tiêu của phần mềm cần phát triển. Thường đó là các yêu cầu chức năng về những gì mà hệ thống phải thực hiện. Ở giai đoạn này chưa cần chỉ ra các chức năng đó thực hiện như thế nào. Việc xác định đúng và đầy đủ các yêu cầu của bài toán là nhiệm vụ rất quan trọng, nó làm cơ sở cho các bước tiếp theo. Do đó, phải đặc tả được các yêu cầu của hệ thống (Sử dụng các Use Case để đặc tả các yêu cầu). 200 3.1.1 Nghiên cứu hiện trạng và xác định các yêu cầu Các công việc cần phải làm trong giai đoạn này: Hiểu rõ miền xác định của bài toán (Domain Understanding) Nắm bắt các yêu cầu của khách hàng/người sử dụng Phân loại (Classification): theo tầm quan trọng hay theo chức năng chính của những người sử dụng. Thẩm định (Validation): Kiểm tra xem các yêu cầu có thống nhất với nhau và đầy đủ không, đồng thời tìm cách giải quyết các mối mâu thuẫn giữa các yêu cầu nếu có. 201 3.1.1 Nghiên cứu hiện trạng và xác định các yêu cầu Nghiên cứu khả thi (Feasibility Study): Tính khả thi của một dự án tin học phải được thực hiện dựa trên các yếu tố bao gồm các khía cạnh:  tài chính  chiến lược  thị trường  con người, đối tác  kỹ thuật  công nghệ và phương pháp mô hình hoá, v.v. 202 3.1.1 Nghiên cứu hiện trạng và xác định các yêu cầu Tóm lại, giai đọan nghiên cứu sơ bộ, cần xem xét: Các yêu cầu của NSD, những nguồn tài nguyên có thể sử dụng, công nghệ, các ý tưởng của người sử dụng đối với hệ thống mới. Có thể thực hiện thảo luận, nghiên cứu, xem xét khía cạnh thương mại, phân tích khả năng lời-lỗ Thường trong giai đoạn này người ta cũng tiến hành tạo một phiên bản thô của lịch trình và kế hoạch sử dụng tài nguyên. Kết quả của giai đoạn nghiên cứu sơ bộ là bản Báo Cáo Kết Quả Nghiên Cứu Tính Khả Thi. Khi hệ thống tương lai được chấp nhận dựa trên bản báo cáo này cũng là lúc giai đoạn Phân tích bắt 203 đầu. 3.1.1 Nghiên cứu hiện trạng và xác định các yêu cầu Mục đích cụ thể của bước xác định yêu cầu: Đi đến thỏa thuận với khách hàng và người dùng về các chức năng của hệ thống-Những gì mà hệ thống phải thực hiện Cho phép các System Developer hiểu rõ hơn các yêu cầu đối với hệ thống Phân định ranh giới của hệ thống Cung cấp cơ sở để hoạch định nội dung kỹ thuật của các vòng lặp Xác định giao diện người dùng cho hệ thống 204 3.1.1 Nghiên cứu hiện trạng và xác định các yêu cầu Khi nào thì kết thúc giai đoạn này? Khách hàng/người sử dụng (NSD) và những người phát triển đã hiểu hoàn toàn hệ thống chưa? Đã nêu được đầy đủ các yêu cầu về chức năng (dịch vụ), đầu vào/ra và những dữ liệu cần thiết chưa? 205 3.1.1 Nghiên cứu hiện trạng và xác định các yêu cầu Mối quan hệ giữa các công việc trong pha phân tích các yêu cầu 206 3.1.2 Phân tích hướng đối tượng  Là giai đoạn quan trọng của quá trình phát triển phần mềm, trong đó mô hình khái niệm phải được mô tả chính xác. Phân tích hướng đối tượng tập trung vào việc tìm kiếm các đối tượng, khái niệm trong lĩnh vực bài toán và xác định mối quan hệ của chúng trong hệ thống. Phân tích hệ thống cần trả lời các câu hỏi sau:  Hệ thống gồm những thành phần, bộ phận, đối tượng nào?  Hệ thống cần thực hiện những cái gì? Kết quả chính của việc phân tích hệ thống hướng đối tượng là: biểu đồ lớp, biểu đồ trạng thái, biểu đồ trình tự, biểu đồ cộng tác và biểu đồ thành phần. 207 3.1.2 Phân tích hướng đối tượng ... Tóm lại, mục tiêu cụ thể của giai đoạn phân tích là: Xác định hệ thống cần phải làm gì. Nghiên cứu đầy đủ các chức năng cần cung cấp và những yếu tố liên quan. Xây dựng một mô hình nêu bật bản chất vấn đề từ một hướng nhìn có thực (trong đời sống thực). Nhờ chuyên gia lĩnh vực đánh giá, góp ý. Kết quả của giai đoạn phân tích là bản Đặc Tả Yêu Cầu (Requirements Specifications). 208 3.1.3 Thiết kế hướng đối tượng  Hệ thống được tổ chức thành tập các đối tượng tương tác với nhau và mô tả được cách để hệ thống thực thi nhiệm vụ của bài toán.  Giai đoạn này cần trả lời các câu hỏi: Hệ thống làm như thế nào? (HOW?)  Trong hệ thống có những lớp đối tượng nào, trách nhiệm của chúng như thế nào?  Các đối tượng tương tác với nhau như thế nào?  Các nhiệm vụ mà mỗi lớp đối tượng phải thực hiện như thế nào?  Dữ liệu nghiệp vụ và các giao diện được xây dựng như thế nào?  Kiến trúc và cấu hình của hệ thống như thế nào? 209 3.1.3 Thiết kế hướng đối tượng Tóm lại, nhiệm vụ chính của thiết kế hệ thống là: Xây dựng các thiết kế chi tiết mô tả các thành phần của hệ thống ở mức cao hơn (khâu phân tích) để phục vụ cho việc cài đặt. Đưa ra được kiến trúc của hệ thống để đảm bảo cho hệ thống có thể thay đổi, có tính mở, dễ bảo trì, thân thiện với NSD, ... Những kết quả trên được thể hiện trong các biểu đồ: biểu đồ lớp (chi tiết), biểu đồ hành vi, biểu đồ thành phần và biểu đồ triển khai. Trong các tài liệu thiết kế phải mô tả cụ thể những thành phần nào, làm những gì và làm như thế nào. 210 3.1.3 Thiết kế hướng đối tượng Một số các công việc thường được thực hiện trong giai đoạn thiết kế: Thiết kế database Thiết kế các chức năng, thủ tục mô tả các quá trình xử lý từ input đến output. Thiết kế các forms nhập dữ liệu tùy theo các thành phần dữ liệu cần nhập. Thiết kế các reports và những output mà hệ thống mới phải sản sinh Kết quả giai đoạn thiết kế là bản Đặc Tả Thiết Kế (Design Specifications). Bản Đặc Tả Thiết Kế Chi Tiết sẽ được chuyển sang cho các lập trình viên để thực hiện giai đoạn xây 211 dựng phần mềm. 3.1.4 Lập trình và kiểm thử hệ thống Trong giai đoạn này, mỗi thành phần đã được thiết kế sẽ được lập trình thành những mô đun chương trình (chương trình con). Mỗi mô đun này sẽ được kiểm chứng hoặc thử nghiệm theo các tài liệu đặc tả của giai đoạn thiết kế.  Công việc này được mô tả như sau: Quá trình xây dựng phần mềm 212 3.1.4 Lập trình và kiểm thử hệ thống Phần kiểm thử được chia thành hai bước chính: Thử nghiệm đơn vị: Người viết code chạy thử các phần chương trình của mình với dữ liệu giả (test/dummy data). Mục đích chính trong giai đoạn kiểm thử này là xem chương trình có cho ra những kết quả mong muốn. Giai đoạn thử nghiệm đơn vị còn được gọi là “Kiểm thử hộp trắng" (White Box Testing) 213 3.1.4 Lập trình và kiểm thử hệ thống Kiểm thử đơn vị độc lập Công việc này do một thành viên khác đảm trách. Cần chọn người không có liên quan trực tiếp đến việc viết code của đơn vị chương trình cần thử nghiệm để đảm bảo tính “độc lập”. Kiểm thử hệ thống Sau khi các thủ tục đã được thử nghiệm riêng, cần phải thử nghiệm toàn bộ hệ thống. Mọi thủ tục được tích hợp và chạy thử, kiểm tra xem mọi chi tiết ghi trong Đặc Tả Yêu Cầu. Dữ liệu kiểm thử cần được chọn lọc đặc biệt, kết quả cần được phân tích để phát hiện các sai sót so 214 với bản thiết kế. 3.1.5 Vận hành và bảo trì hệ thống Cài đặt hệ thống phần mềm trong môi trường sử dụng của khách hàng Chỉnh sửa phần mềm đúng như những gì đã thiết kế và yêu cầu của người sử dụng Về bảo trì phần mềm:  Nâng cao hiệu quả của hệ thống  Đảm bảo sự thích nghi đối với sự thay đổi của môi trường của hệ thống hay sự sửa đổi cho phù hợp với những thay đổi của chính sách, qui chế mới 215 3.1. QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM HĐT ... 216 Qui trình xây dựng các biểu đồ UML trong phân tích, thiết kế hệ thống HĐT 3.2. PHÂN TÍCH YÊU CẦU HỆ THỐNG BÀI TOÁN 1: HỆ THỐNG BÁN HÀNG (HBH) Một Công ty muốn xây dựng HTTT để phục vụ và quản lý các hoạt động kinh doanh. Công ty có nhiều điểm bán hàng đầu cuối (POST: Point Of Sale Terminal), đó là những cửa hàng, siêu thị, ... Do đó hệ thống cần phải ghi nhận các hoạt động bán hàng và xử lý các công việc thanh toán với khách hàng, chủ yếu khách hàng mua lẻ. Ngoài ra hệ thống còn giúp lãnh đạo Công ty theo dõi được các hoạt động kinh doanh, tự động kiểm kê các mặt hàng tồn đọng trong kho, các mặt hàng bán chạy,... để hỗ trợ ra quyết định trong các hoạt động kinh doanh của Công ty. Trong mỗi cửa hàng đầu cuối đều có các thiết bị phần cứng như: máy tính, máy đọc mã vạch và phần mềm hệ thống để chạy hệ thống sẽ được xây dựng”. 217 Mục đích của hệ thống HBH  Tăng nhanh hoặc tự động hoá việc bán hàng, ghi nhận các mặt hàng: loại sản phẩm, mô tả sản phẩm, số lượng và xác định giá bán, tính tiền, v.v., đáp ứng mọi yêu cầu của khách hàng,  Thanh toán nhanh với khách hàng bằng các phương thức: tiền mặt, thẻ tín dụng, hay séc.  Phân tích, xử lý các kết quả bán hàng nhanh và chính xác để hỗ trợ quyết định trong các hoạt động kinh doanh.  Thực hiện tự động kiểm kê các mặt hàng trong kho, theo dõi được những mặt hàng bán chạy, những mặt hàng tồn kho để có được những quyết định kịp thời trong kinh doanh.  Tóm lại, hệ thống xây dựng nhằm tự động hoá các hoạt động kinh doanh, phục vụ khách hàng nhanh hơn, tốt hơn và rẻ hơn. 218 Trong giai đoạn phân tích Đối với bài toán 1, giai đoạn OOA sẽ nhận biết được các đối tượng như: - Cửa hàng, siêu thị - Khách hàng - Mặt hàng - Người thanh toán - ... Tương tác và quan hệ giữa các đối tượng trên là: - Khách hàng chọn hàng - Khách hàng trả tiền - ... 219 BÀI TOÁN 2: HỆ THỐNG ATM Ngân hàng VietinBank có các máy rút tiền tự động (ATM) đặt ở những vị trí khác nhau trong thành phố. Chúng được nối với Trung tâm tại trụ sở Ngân hàng thông qua hệ thống mạng máy tính. Máy tính trung tâm lưu trữ và quản trị CSDL khách hàng, xử lý những công việc chuyên ngành của ngân hàng và yêu cầu ATM trả tiền. Máy rút tiền tự động bao gồm máy đọc thẻ từ, màn hình và bàn phím để tương tác với người sử dụng. Khách hàng có thể rút tiền tự động, chuyển tiền, xem số dư trong tài khoản và thực hiện thanh toán với hệ thống tín dụng của Ngân hàng. 220 BÀI TOÁN 2: HỆ THỐNG ATM ... Trong những trường hợp đặc biệt như bị mất thẻ, hay muốn thay đổi số thẻ thì khách hàng có thể thay đổi mật khẩu cá nhân (PIN) và tương tự như vậy, khi khách hàng báo bị mất thẻ thì Ngân hàng cũng có thể quyết định thay đổi số thẻ và báo cho khách hàng biết để đảm bảo không cho những người không phải chủ sở hữu rút được tiền. 221 BÀI TOÁN 3: HỆ THỐNG ĐĂNG KÝ HỌC PHẦN  Đại học Huế cần xây dựng một hệ thống thông tin giúp sinh viên (SV) đăng ký học phần (HP) mới. Hệ thống cho phép SV đăng ký học phần và xem điểm từ một máy tính cá nhân được kết nối vào hệ thống mạng của ĐHH. Các giáo viên cũng có thể truy cập vào hệ thống này để biết được lớp dạy và nhập điểm cho các HP.  Vào đầu mỗi học kỳ SV dựa vào TKB và giáo viên sẽ phụ trách môn học để đăng ký HP được giảng dạy trong học kỳ đó. Thông tin về mỗi HP bao gồm: tên HP, tên giáo viên giảng dạy, Khoa chuyên môn, các HP tiên quyết,... để giup SV đăng ký.  Hệ thống mới cho phép SV chọn 4 học phần được mở trong học kỳ tới. SV cũng có thể chọn 2 HP tự chọn trong trường hợp không thể đăng ký theo nguyện vọng chính.  Số tối thiểu và tối đa SV cho mỗi HP là 30 và 60. Các HP có ít hơn 30 SV sẽ bị hủy. Đầu mỗi HP SV có một khoảng thời gian để thay đổi các HP đã đăng ký. BÀI TOÁN 3: HỆ THỐNG ĐĂNG KÝ HỌC PHẦN  Khi quá trình đăng ký hoàn tất cho mỗi SV hệ thống sẽ gửi thông tin đến ngân hàng VietinBank để SV có thể đóng học phí qua thẻ ATM  Nếu một lớp bị hết chỗ trong quá trình đăng ký, SV sẽ được thông báo về sự thay đổi trước khi xác nhận đăng ký HP  Cuối học kỳ SV có thể truy cập vào hệ thống để xem phiếu điểm. Hiễn nhiên, mỗi SV được hệ thống cung cấp một tài khoản cá nhân để bảo mật thông tin của mình.  Các giáo viên có thể truy cập vào hệ thống để biết TKB và danh sách SV của HP sẽ dạy  Giáo viên có nhiệm vụ nhập các điểm QTHT, điểm thi, kiểm tra sau khi HP kết thúc 223 Các công cụ để mô tả yêu cầu người dùng 224 Các chức năng, nhiệm vụ của hệ thống là gì? Chức năng của hệ thống là những gì mà hệ thống được yêu cầu thực hiện. Các chức năng có thể phân loại theo lĩnh vực chức năng để tránh sự nhầm lẫn giữa chúng. Các chức năng hệ thống có thể chia thành:  Chức năng hiển (Evident): chọn hàng, tính tiền,...  Chức năng ẩn (Hiddent): cập nhật dữ liệu, tồn kho  Chức năng tuỳ chọn (optional): tăng mức độ thân thiện của hệ thống nhưng không ảnh hưởng tới giá trị cũng như các chức năng khác. 225 Các chức năng, nhiệm vụ của hệ thống là gì? Chú ý: Các chức năng của hệ thống phải được chia thành các nhóm theo các mối liên hệ với nhau. Dựa vào cách phân chia các chức năng để sau này chia nhỏ hệ thống thành các gói, các hệ thống con trong quá trình phân tích và thiết kế hệ thống. Ví dụ: Các chức năng của hệ thống HBH có thể chia thành hai nhóm chính:  Các chức năng bán hàng  Các chức năng thanh toán. 226 Bảng liệt kê các chức năng 227 Bảng liệt kê các chức năng  Các chức năng hệ thống thường được đánh số theo các qui tắc tham chiếu (Reference Rule) để tiện cho việc sử dụng tham chiếu trong các mục phân tích sau này. 228 3.3. ĐẶC TẢ CÁC YÊU CẦU CỦA HỆ THỐNG 1. Use Case Use Case mô tả tập các hoạt động của hệ thống theo quan điểm của các tác nhân (Actor). Nó mô tả các yêu cầu của hệ thống và trả lời cho câu hỏi: Hệ thống phải làm gì (What ?) Một Use Case có thể bao gồm nhiều biểu đồ Use Case Use Case mô tả rõ ràng và nhất quán về việc hệ thống cần phải làm gì (What?). Use Case mô tả các yêu cầu về mặt chức năng của hệ thống -các chức năng này có từ sự thỏa thuận giữa khách hàng và nhóm phát triển phần mềm. 229 2. Mục tiêu của Use Case Làm cơ sở để:  người phân tích viên hiểu  người thiết kế xây dựng các kiến trúc  người lập trình cài đặt các chức năng  người kiểm thử kiểm tra các kết quả thực hiện của hệ thống. Làm công cụ giao tiếp cho những người phát triển, đảm bảo hệ thống thỏa mãn đúng những yêu cầu của Users 230 3. Ai cần Use Case? - Để làm gì? Nhà phát triển cần đến các mô hình Use Case để hiểu hệ thống cần phải làm gì, và qua đó có được một nền tảng cho những công việc tương lai Customers/Users quan tâm đến Use Case vì nó đặc tả chức năng của hệ thống và mô tả xem hệ thống có thể và sẽ được sử dụng như thế nào. Tester cần đến Use Case để thử nghiệm và kiểm tra xem hệ thống có đảm bảo sẽ thực hiện đúng chức năng đã được đặc tả trong giai đoạn đầu. Những người liên quan đến những hoạt động liên kết đến chức năng của hệ thống như nhóm tiếp thị, bán hàng, hỗ trợ khách hàng và nhóm soạn thảo tài liệu.231 4. Cách thể hiện một biểu đồ Use Case Một biểu đồ Use Case thể hiện: Hệ thống Actors Hệ thống Tác nhân Use Case. Ví dụ biểu đồ Use Case trong UML: Use Case 232 a. Hệ thống Hệ thống là một thành phần của Use Case nên ranh giới của hệ thống cần phải được xác định rõ ràng. Một hệ thống không nhất thiết là một hệ thống phần mềm; nó có thể là một chiếc máy, hoặc là một doanh nghiệp. Ký hiệu của hệ thống: hình chữ nhật có kèm theo tên hệ thống System Boundary UseCase 233 b. Tác nhân Người hoặc một vật nào đó tương tác với hệ thống, sử dụng hệ thống. Một tác nhân có thể là người, thiết bị mà cũng có thể là một hệ thống khác. Tên gọi của tác nhân được mô tả bằng các danh từ (chung) và thường phải đặc tả được vai trò của nó đối với hệ thống. Một tác nhân là một dạng tập thực thể (một lớp) chứ không phải một thực thể. Tác nhân mô tả và đại diện cho một vai trò, chứ không phải là một người sử dụng thật sự và cụ thể của hệ thống. 234 c. Bảng chú giải  Dùng để giải thích các khái niệm, định nghĩa, thuật ngữ, ngôn ngữ công việc trong hệ thống 235 5. Cách xác định các tác nhân và các Use Case a. Để xác định các tác nhân là dựa trên các câu trả lời những câu hỏi sau: Ai sẽ sử dụng các chức năng chính của hệ thống? Ai cần sự hỗ trợ của hệ thống để thực hiện các công việc hàng ngày? Ai quản trị, bảo dưỡng để đảm bảo cho hệ thống hoạt động thường xuyên? Hệ thống quản lý, sử dụng những thiết bị nào? Hệ thống cần tương tác với những bộ phận, hệ thống nào khác? Ai hay cái gì quan tâm đến kết quả xử lý của hệ thống? 236 5. Cách xác định các tác nhân và các Use Case b. Có hai phương pháp để xác định các Use Case  Xác định Use Case dựa vào các tác nhân: Xác định những tác nhân liên quan đến hệ thống hoặc đến tổ chức, nghĩa là tìm và xác định những tác nhân là NSD hay những hệ thống khác tương tác với hệ thống cần xây dựng. Với mỗi tác nhân, tìm những tiến trình (chức năng) được khởi đầu, hay giúp các tác nhân thực hiện, giao tiếp/tương tác với hệ thống. 237 Xác định các Use Case và các sự kiện Xác định những sự kiện bên ngoài có tác động đến hệ thống hay hệ thống phải trả lời. Tìm mối liên quan giữa các sự kiện và các UC. Hãy trả lời những câu hỏi sau để tìm ra các UC:  Nhiệm vụ chính của các tác nhân là gì?  Tác nhân cần phải đọc, ghi, sửa đổi, cập nhật, hay lưu trữ thông tin hay không?  Những thay đổi bên ngoài hệ thống thì tác nhân có cần phải thông báo cho hệ thống hay không?  Những tác nhân nào cần được thông báo về những thay đổi của hệ thống?  Hệ thống cần có những đầu vào/ra nào? từ đâu và đến đâu? 238 Ví dụ1: Xác định các Actor và Use Case của HBH a. Xác định các actor: Danh sách các actor + Khách hàng: là những người được hệ HBH phục vụ, là khách hàng. + Người bán hàng: những người cần sử dụng chức năng bán hàng của hệ thống để thực hiện nhiệm vụ của mình. + Người quản lý: những người được phép khởi động hay kết thúc cả hệ thống tại các điểm bán hàng đầu cuối. + Người quản trị hệ thống: có thể bổ sung, thay đổi những NSD. 239 Ví dụ1: Xác định các Actor và Use Case của HBH ... b. Xác định các Use Case: Danh sách các Use Case  Bán hàng, mua hàng (Buy Items) là nhiệm vụ của hệ thống HBH liên quan trực tiếp tới khách hàng và người bán hàng. Use Case Use Case này liên quan đến cả người bán hàng và khách hàng.  Thanh toán, trả tiền mua hàng hay thu tiền là chức năng của hệ thống phải thực hiện để thanh toán với khách hàng bằng phương thức mà họ lựa chọn: trả tiền mặt, thẻ tín dụng, hay trả bằng séc. Use Case này cũng liên quan đến cả người bán hàng và khách hàng. 240 Ví dụ1: Xác định các Actor và Use Case của HBH ... b. Xác định các Use Case: Danh sách các Use Case  Đăng nhập hệ thống (Log in): Người bán hàng cần sử dụng để nhập vào hệ thống và sử dụng nó để bán hàng.  Khởi động, đóng hệ thống: Người quản lý thực hiện để khởi động hay kết thúc hoạt động của hệ thống.  Bổ sung NSD mới, Loại bỏ NSD: Người quản trị hệ thống có thể bổ sung thêm người sử dụng mới hay loại bỏ những NSD không còn cần sử dụng hệ thống. 241 Các Actor và Use Case của hệ thống HBH Tác nhân Người bán hàng (Cashier) Use Case Đăng nhập hệ thống (Log In) Thu tiền bán hàng (Cash Out) Khách hàng (Customer) Mua hàng (Buy Items) Thu tiền, thanh toán (Refund Items) Người quản lý (Manager) Hay gian hàng trưởng Quản trị hệ thống (System Adminitrator) Khởi động hệ thống (Start Up) để người bán hàng có thể sử dụng HT. Đóng hệ thống khi hết giờ Bổ sung NSD (Add New Users) Loại bỏ NSD (Delete User) 242 Biểu đồ Use Case của hệ thống HBH 243 Ví dụ2: Các Actor và Use Case của hệ thống ATM a. Xác định các actor: Danh sách các actor Khách hàng: những đối tượng chính mà hệ thống ATM phục vụ việc rút/gửi tiền tự động. Hệ thống tín dụng: bộ phận tín dụng của Ngân hàng quản lý và phục vụ tín dụng cho khách hàng. Nhân viên ngân hàng: những người được quyền thay đổi PIN của khách hàng khi cần thiết, chuyển tền vào máy. 244 Ví dụ2: Các Actor và Use Case của hệ thống ATM b. Xác định các Use Case: Danh sách các Use Case Rút tiền: những khách hàng có tiền trong tài khoản của Ngân hàng, khi cần rút tiền thì nhập số PIN, nhập số lượng tiền cần rút. Chuyển tiền: khách hàng có thể chuyển tiền từ một tài khoản khác về tài khoản của mình hoặc gửi tiền trực tiếp vào tài khoản. Xem số dư trong tài khoản: khách hàng biết được mình còn bao nhiêu tiền trong tài khoản. Thanh toán: khách hàng có thể sử dụng để thanh toán với hệ thống tín dụng của Ngân hàng. Thay đổi PIN: khách hàng, hoặc nhân viên Ngân hàng 245 có thể thay đổi PIN khi cần thiết. Biểu đồ Use Case của hệ thống ATM 246 6. Đặc tả các Use Case b. Mục đích : Để hiểu rõ hơn về tiến trình xử lý các yêu cầu của hệ thống. Mẫu đặc tả Use Case có dạng: Tên Use Case: tên của Use Case bắt đầu bằng động từ, gợi nhớ. Các tác nhân: danh sách các tác nhân liên quan đến Use Case.  Mô tả mục đích :Mô tả tóm tắt tiến trình xử lý công việc cần thực hiện. Tham chiếu: Các chức năng, Use Case và những hệ thống liên quan. 247 Ví dụ Use Case: Bán hàng (Buy Items) Tác nhân: Khách hàng, người bán hàng. Mô tả: Khách hàng sau khi đã chọn đủ các mặt hàng cần mua để ở trong giỏ hàng thì đưa hàng đến quầy thu tiền. Người bán (cashier) lần lượt ghi nhận các mặt hàng trong giỏ hàng của khách và thu tiền. Sau khi thanh toán xong khách hàng được mang số hàng đã mua đi ra khỏi cửa hàng. Tham chiếu tới: Các chức năng R1.1, R1.2, R1.3, R1.6, R1.7, R1.8, R3.1, R3.2, R3.3. 248 Ví dụ Use Case cho chức năng Bán hàng (Buy items) Bán hàng Khách hàng Người bán hàng 249 Ví dụ Use Case: Thu tiền (Cash Out) Tác nhân: Khách hàng, người bán hàng. Mô tả: Khách hàng có thể trả tiền theo 3 phương thức: 1. Trả tiền mặt (Pay by Cash) 3. Trả bằng thẻ tín dụng (Pay by Credit) 3. Trả bằng séc (Pay by Check) Người bán nhận tiền mặt/thẻ tín dụng/sec rồi thanh toán tiền thừa cho khách hàng sau khi thẻ tín dụng/sec đã được kiểm duyệt. Tham chiếu tới: Các chức năng R1.1, R1.2, R1.3, R1.9, R3.1, R3.2, R3.3. 250 Use Case cho chức năng Thu tiền (Cash Out) Pay by Check Bộ phận kiểm duyệt thẻ Bộ phận kiểm duyệt sec Pay by Credit <<uses>> Pay by Cash <<uses>> <<uses>> Khách hàng Cash Out Người bán hàng 251 Use Case cho chức năng Thu tiền (Cash Out) Chú ý: Ngoài những đặc tả nêu trên, ta còn có thể xây dựng các kịch bản (scenario) hành động để mô tả các sự kiện xảy ra trong hệ thống. Mỗi kịch bản có thể mô tả theo hai luồng:  Luồng thực hiện của các tác nhân  Luồng tương ứng với hệ thống. (Xem thêm phần xây dựng kịch bản ở trang 57, 58 của giáo trình) 252 7. Mối quan hệ giữa các Use Case Giữa các Use Case có ba quan hệ chính:  Quan hệ mở rộng (extends) <<extends>>  Quan hệ sử dụng (uses/include) <<uses>>  Quan hệ theo nhóm hay theo gói (package). 253 8. Checkpoint - Use Case Model Kiểm tra đã hoàn tất việc xác định yêu cầu của người dùng chưa? a. Kiểm tra về Use Case Model và Use Case 1.Use-case model có dễ hiểu không? 2.Sau khi nghiên cứu Use Case model, bạn có hình thành được một ý tưởng rõ ràng về các chức năng của hệ thống và cách thức mà chúng liên hệ với nhau? 3.Đã xác định hết các actor chưa? Tất cả các yêu cầu chức năng được thỏa mãn chưa? 4.Use-case model có chứa các hành vi vô dụng nào không? 8. Checkpoint 5. Việc chia các Use Case thành các Package có xác đáng không? 6. Mỗi Use Case có ít nhất một actor tương tác? 7. Các Use Case có độc lập với nhau? 8. Tồn tại các Use Case có các luồng sự kiện và các hành vi tương tự nhau không? 9. Liệu các Use Case có tên duy nhất, gợi nhớ, dễ hiểu để chúng không bị nhầm lẫn trong các giai đọan sau? 10.Các customers và users có hiểu tên và mô tả của các Use Case không? 8. Checkpoint - Actors b. Kiểm tra các Actors 1. Đã xác định hết các actor chưa? 2. Mỗi actor có tham gia vào ít nhất một Use Case? 3. Mỗi actor thật sự có một vai trò (role)? Có cần ghép hoặc tách các actor không? 4. Có tồn tại 2 actor đóng cùng một vai trò đối với 1 Use Case không? 5. Tên của các actor có gợi nhớ không? Users và customers có hiểu tên của chúng? 8. Checkpoint - Glossary c. Kiểm tra các Glossary 1. Các thuật ngữ có định nghĩa rõ ràng và súc tích? 2. Mỗi thuật ngữ có sử dụng đâu đó trong các mô tả Use Case? 3. Các thuật ngữ có được sử dụng hợp lý trong các mô tả ngắn về các actors và Use Case? 3.4. THIẾT KẾ HƯỚNG ĐỐI TƯỢNG 3.4.1. Vai trò của thiết kế  Thiết kế là 1 công đoạn quan trọng trong qui trình phát triển phần mềm; là bước chuyển tiếp của giai đoạn phân tích và là bước chuẩn bị trước khi tiến hành xây dựng phần mềm.  Thiết kế là tiến trình mà ở đó xuất hiện mô hình các kiểu mẫu của phần mềm. Các mô hình này chính là những nét phác thảo nên phần mềm. Nó cho chúng ta biết phần mềm chúng ta đang xây dựng là gì, đã có, đang có và sẽ có những gì.  Thiết kế là nơi mà ta có thể trả lời câu hỏi :  “Liệu phần mềm này có thể chạy được không?”  “Phần mềm có thể đáp ứng được các yêu cầu của khách hàng hay không?” mà không cần đợi đến công đoạn phát triển sau. 258 3.4. THIẾT KẾ HƯỚNG ĐỐI TƯỢNG ... 3.4.2. Các nguyên lý thiết kế Nguyên lý ‘đóng mở’: một modun cần “mở” đối với việc phát triển thêm tính năng nhưng phải “đóng” đối với việc sửa đổi mã nguồn Nguyên lý thay thế Liskov: Các chức năng của hệ thống vẫn thực hiện đúng đắn nếu ta thay bất kì một lớp đối tượng nào bằng một lớp đối tượng kế thừa. Nguyên lý nghịch đảo phụ thuộc: phụ thuộc vào mức trừu tượng, không phụ thuộc vào mức chi tiết. Nguyên lý phân tách giao diện: nên có nhiều giao diện đặc thù với bên ngoài hơn là chỉ có một 259 giao diện dùng chung cho một mục đích. 3.5. CÁC NHÓM MẪU THIẾT KẾ 3.5.1. Sự quan trọng của mẫu thiết kế Trong bất kỳ một hệ thống hướng đối tượng nào cũng có thể gặp các vấn đề lặp lại. Do đó, một mẫu thiết kế là một giải pháp tổng thể cho các vấn đề chung trong thiết kế phần mềm.  Mẫu thiết kế tuân thủ nghiêm ngặt các nguyên lý thiết kế hướng đối tượng ở trên.  Mẫu thiết kế không phụ thuộc vào ngôn ngữ lập trình, công nghệ, và nó có các quy tắc biểu diễn của ngôn ngữ UML. 260 3.5. CÁC NHÓM MẪU THIẾT KẾ ... 3.5.2. Sự quan trọng của mẫu thiết kế ... Mẫu thiết kế sẽ giúp cho việc giải quyết vấn đề nhanh, gọn hơn và hợp lý hơn. Mẫu thiết kế còn được sử dụng nhằm cô lập các thay đổi trong mã nguồn, từ đó làm cho hệ thống có khả năng tái sử dụng cao. Chúng ta sẽ tìm hiểu một số mẫu thiết kế kinh điển GoF - Gang of Four - bốn tác giả Erich Gamma, Richard Helm, Ralph Johnson và John Vlissides của cuốn sách Design Patterns: Elements of Reusable Object-Oriented Software (Download ở site: http://www.uml.org.cn/c++/pdf/DesignPatterns.pdf) 261 3.5. CÁC NHÓM MẪU THIẾT KẾ ... 3.5.3. Các loại mẫu thiết kế GoF đề xuất 23 mẫu thiết kế được chia theo 3 nhóm theo mục đích sử dụng:  Creational Patterns – Các mẫu kiến tạo  Structural Patterns – Các mẫu kiến trúc  Behavioral Patterns – Các mẫu tương tác 262 a. CÁC NHÓM MẪU THIẾT KẾ 1. Các mẫu thuộc nhóm kiến tạo - Creational Patterns 2. Các mẫu thuộc nhóm kiến trúc - Structural Patterns 263 a. CÁC NHÓM MẪU THIẾT KẾ ... 1. Các mẫu thuộc nhóm tương tác - Behavioral Patterns 264 b. CÁC MẪU THUỘC NHÓM KIẾN TẠO - CREATIONAL PATTERNS Mục đích chung: Các mẫu này được dùng để khởi tạo các đối tượng trong hệ thống. Hầu hết các hệ thống hướng đối tượng phức tạp yêu cầu nhiều đối tượng được thể hiện theo thời gian, và các mẫu này hỗ trợ cho việc tạo các tiến trình bằng việc cung cấp các khả năng:  Sự thể hiện chung – Điều này cho phép các đối tượng được tạo ra trong hệ thống không cần phải định nghĩa một đặc tả kiểu lớp trong mã nguồn  Đơn giản – Một vài mẫu làm cho việc khởi tạo đối tượng trở nên dễ dàng, vì vậy lớp “gọi” khởi tạo đối tượng không phải viết mã nhiều cũng như phức tạp 265 Mẫu Abstract Factory 1.Ý nghĩa: Abstract Factory cung cấp 1 giao diện để tạo ra đối tượng mà không phải mô tả các lớp cụ thể. Abstract Factory dùng để đóng gói một nhóm gồm những lớp đóng vai trò là “phân xưởng” (Factory) trong ứng dụng, đây là những lớp được dùng để tạo lập các đối tượng. Các lớp “phân xưởng” này có chung một giao diện lập trình được kế thừa từ một lớp cha thuần ảo gọi là “lớp phân xưởng ảo” 266 2. Cấu trúc mẫu: 267 Trong đó:  AbstractFactory: là lớp trừu tượng, tạo ra các đối tượng thuộc 2 lớp trừu tượng là: AbstractProductA và AbstractProductB  ConcreteFactoryX: là lớp kế thừa từ AbstractFatory, lớp này sẽ tạo ra một đối tượng cụ thể  AbstractProduct: là các lớp trừu tượng, các đối tượng cụ thể 268 sẽ là các thể hiện của các lớp dẫn xuất từ lớp này. 2. Cấu trúc mẫu: 1 game, trong đó có thú ăn thịt và thú ăn cỏ Thú ăn thịt: Sư tử, Sói Thú ăn cỏ: Linh dương, Bò rừng Phân biệt theo các châu Châu Phi: Sư tử, Linh dương Châu Mỹ: Sói, Bò rừng 269 The classes and/or objects participating in this pattern are: AbstractFactory (ContinentFactory) declares an interface for operations that create abstract products ConcreteFactory (AfricaFactory, AmericaFactory) implements the operations to create concrete product objects AbstractProduct (Herbivore, Carnivore) declares an interface for a type of product object Product (Wildebeest, Lion, Bison, Wolf) defines a product object to be created by the corresponding concrete factory implements the AbstractProduct interface Client (AnimalWorld) uses interfaces declared by AbstractFactory and AbstractProduct classes Xem code in C# tại: http://www.dofactory.com/Patterns/PatternAbstract.aspx 270 Mẫu Abstract Factory 3. Tình huống áp dụng Phía trình khách sẽ không phụ thuộc vào việc những sản phẩm được tạo ra như thế nào. Ứng dụng sẽ được cấu hình với một hoặc nhiều họ sản phẩm. Các đối tượng cần phải được tạo ra như một tập hợp để có thể tương thích với nhau. Chúng ta muốn cung cấp một tập các lớp và chúng ta muốn thể hiện các ràng buộc, các mối quan hệ giữa chúng mà không phải là các thực thi của chúng (interface). 271 Mẫu Abstract Factory ... 4. Ví dụ: Giả sử ta cần viết một ứng dụng quản lý địa chỉ và số điện thoại cho các quốc gia trên thế giới. Điạ chỉ và số địa thoại của mỗi quốc gia sẽ có 1 số điểm giống nhau và 1 số điểm khác nhau. Ta xây dựng sơ đồ lớp như sau: 272 Ta sẽ xây dựng các phương thức tạo Address, và PhoneNumber cụ thể trong các lớp: • USAAddressPhoneFactory • FrechAddressPhoneFactory. Với phương thức createProductAddress() của lớp USAAddressPhoneFactory sẽ trả về đối tượng của lớp USAAddress Với phương thức createProductAddress() của lớp FrechAddressPhoneFactory sẽ trả về đối tượng của lớp FrechAddress Tương tự với PhoneNumber. 273 Mẫu Builder 1.Ý nghĩa: Tách các thành phần của một đối tượng phức hợp, để có thể cùng khởi tạo một lần mà có thể tạo nên nhiều định dạng khác nhau. 274 2. Cấu trúc mẫu: Trong đó,  Director: là lớp điều khiển tạo ra một đối tượng Product  Builder: là lớp trừu tượng cho phép tạo ra đối tượng Product từ các phương thức nhỏ khởi tạo từng thành phần của Product  ConcreteBuilder: là lớp dẫn xuất của Builder, khởi tạo từng đối tượng cụ thể, lớp này sẽ khởi tạo đối tượng. 275 Mẫu Builder ... 3. Tình huống áp dụng Có cấu trúc bên trong phức tạp (đặc biệt là một biến là một tập các đối tượng liên quan với nhau) Có các thuộc tính phụ thuộc vào các thuộc tính khác Sử dụng các đối tượng khác trong hệ thống mà có thể khó khởi tạo hoặc khởi tạo phức tạp. 4. Ví dụ Ta lại xét đối tượng Address, có các thành phần sau: Street, City và Region. Ta phân tách việc khởi tạo 1 đối tượng Address thành các phần : buildStreet, buildCity và buildRegion. 276 Mẫu Builder ... Trong đó:  AddressDirector: là lớp tạo ra đối tượng Address  AddressBuilder: là lớp trừu tượng cho phép tạo ra 1 đối tượng Address bằng các phương thức khởi tạo từng thành phần của Address  USAddressBuilder: là lớp tạo ra các Address. USAddressBuilder 277 sẽ tạo ra địa chỉ theo chuẩn của USA Mẫu Factory Method 1.Ý nghĩa: Định nghĩa một phương thức chuẩn để khởi tạo đối tượng, như là một phần của phương thức tạo, nhưng việc quyết định kiểu đối tượng nào được tạo ra thì phụ thuộc vào các lớp con. 278 2. Cấu trúc mẫu: Trong đó,  Creator là lớp trừu tượng, khai báo phương thức factoryMethod() nhưng không cài đặt  Product cũng là lớp trừu tượng  ConcreteCreatorA và ConcreteCreatorB là 2 lớp kế thừa từ lớp Creator để tạo ra các đối tượng riêng biệt  ConcreteProductA và ConcreteProductB là các lớp kế thừa của lớp Product, các đối tượng của 2 lớp này sẽ do 2 lớp ConcreteCreatorA và 279 ConcreteCreatorB tạo ra Mẫu Factory Method ... 3. Tình huống áp dụng Khi bạn muốn tạo ra một framework có thể mở rộng, có nghĩa là nó cho phép tính mềm dẻo trong một số quyết định như chỉ ra loại đối tượng nào được tạo ra Khi bạn muốn 1 lớp con, mở rộng từ 1 lớp cha, quyết định lại đối tượng được khởi tạo. Khi bạn biết khi nào thì khởi tạo một đối tượng nhưng không biết loại đối tượng nào được khởi tạo Bạn cần một vài khai báo chồng phương thức tạo với danh sách các tham số như nhau, điều mà Java không cho phép. Thay vì điều đó ta sử dụng các Factory Method với các tên khác nhau. 280 4. Ví dụ: Xét lại ví dụ về các địa chỉ ở phần Abstract Pattern 281 4.3.4. Mẫu Prototype 1.Ý nghĩa: Giúp khởi tạo đối tượng bằng cách copy một đối tượng khác đã tồn tại (đối tượng này là “prototype” – nguyên mẫu). 282 Mẫu Prototype 2. Cấu trúc mẫu: Trong đó: Prototype là lớp trừu tượng cài đặt phương thức myClone() là phương thức copy bản thân đối tượng đã tồn tại. ConcretePrototype1 và ConcretePrototype2 là các lớp kế thừa lớp Prototype. 283 Mẫu Prototype 3. Tình huống áp dụng Khi bạn muốn khởi tạo một đối tượng bằng cách sao chép từ một đối tượng đã tồn tại. 4. Ví dụ: Xét lại ví dụ về các địa chỉ ở phần Abstract Pattern 284 Mẫu Singleton 1.Ý nghĩa: Mẫu này được thiết kế để đảm bảo cho một lớp chỉ có thể tạo ra duy nhất một thể hiện của nó. 2. Cấu trúc mẫu: Trong đó: Singleton cung cấp một phương thức tạo private, duy trì một thuộc tính tĩnh để tham chiếu đến một thể hiện của lớp Singleton này, và nó cung cấp thêm một phương thức tĩnh trả về thuộc tính tĩnh này. 285 Mẫu Singleton ... 3. Tình huống áp dụng Khi bạn muốn lớp chỉ có 1 thể hiện duy nhất và nó có hiệu lực ở mọi nơi. 286 c. NHÓM CÁC MẪU CẤU TRÚC- Structural Patterns Mục đích chung: Đề cập đến việc các đối tượng kết hợp với nhau để tạo thành các cấu trúc hữu dụng hơn Các mẫu Structural diễn tả một cách có hiệu quả cả việc phân chia hoặc kết hợp các phần tử trong một ứng dụng. Những cách mà các mẫu Structural áp dụng vào ứng dụng rất rộng: chẳng hạn,  Mẫu Adapter có thể làm cho hai hệ thống không tương thích có thể giao tiếp với nhau,  Mẫu Façade cho phép bạn làm đơn giản hóa một giao tiếp để sử dụng mà không cần gỡ bỏ tất cả các tùy biến đã có trong hệ thống. 287 Mẫu Adapter 1. Ý nghĩa: Tạo một giao diện trung gian để gắn kết vào hệ thống một lớp đối tượng mong muốn nào đó. 2. Cấu trúc mẫu: Tagret là một interface định nghĩa chức năng, yêu cầu mà Client cần sử dụng Adaptee là lớp chức các chức năng mà Target cần sử dụng để tạo ra được chức năng mà Target cần cung cấp cho Client Adapter thực thi từ Target và sử dụng đối tượng lớp Adaptee, Apdater có nhiệm vụ gắn kết Adaptee vào Target để có được chức năng mà Client mong muốn 288 Mẫu Adapter 3. Tình huống áp dụng  Muốn sử dụng 1 lớp có sẵn nhưng giao tiếp của nó không tương thích với yêu cầu hiện tại  Muốn tạo 1 lớp có thể sử dụng lại mà lớp này có thể làm việc được với những lớp khác không liên hệ gì với nó, và là những lớp không cần thiết tương thích trong giao diện. 4. Ví dụ:  Có một hệ thống PhoneTarget cần thực hiện một chức năng gì đó, trong đó có một phương thức trả về số điện thoại trong một chuỗi đầu vào  Trước đó ta đã có một lớp có một chức năng là lấy các kí tự số trong một chuỗi  Giờ ta muốn sử dụng chức năng lấy kí tự số vào hệ thống lấy số điện thoại 289 Mẫu Bridge 1. Ý nghĩa: Một thành phần trong OOP thường có 2 phần: phần ảo – định nghĩa các chức năng và phần thực thi – thực thi các chức năng được định nghĩa trong phần ảo. Hai phần này liên hệ với nhau qua quan hệ kế thừa. Những thay đổi trong phần ảo dẫn đến các thay đổi trong phần thực thi. Mẫu Bridge được sử dụng để tách thành phần ảo và thành phần thực thi riêng biệt, do đó các thành phần này có thể thay đổi độc lập và linh động. Thay vì liên hệ với nhau bằng quan hệ kế thừa hai thành phần này liên hệ với nhau thông qua quan hệ “chứa trong”. 2. Cấu trúc mẫu: 290 4.4.2 Mẫu Bridge Trong đó: o Abstraction: là lớp trừu tượng khai báo các chức năng và cấu trúc cơ bản, trong lớp này có 1 thuộc tính là 1 thể hiện của giao tiếp Implementation, thể hiện này bằng các phương thức của mình sẽ thực hiện các chức năng abstractionOp() của lớp Abstraction o Implementation: là giao tiếp thực thi của lớp các chức năng nào đó của Abstraction o RefineAbstraction: là định nghĩa các chức năng mới hoặc các chức năng đã có trong Absrtaction. o ConcreteImplement: là các lớp định nghĩa tường minh các thực thi trong lớp 291 giao tiếp Implementation Mẫu Bridge 3. Tình huống áp dụng Khi bạn muốn tạo ra sự mềm dẻo giữa 2 thành phần ảo và thực thi của một thành phần, và tránh đi mối quan hệ tĩnh giữa chúng. Khi bạn muốn những thay đổi của phần thực thi sẽ không ảnh hưởng đến client. Bạn định nghĩa nhiều thành phần ảo và thực thi. Phân lớp con một cách thích hợp, nhưng bạn muốn quản lý 2 thành phần của hệ thống một các riêng biệt 292 Mẫu Composite 1. Ý nghĩa: Mẫu này nhằm gom các đối tượng vào trong một cấu trúc cây để thể hiện được cấu trúc tổng quát của nó. Trong khi đó cho phép mỗi phần tử của cấu trúc cây có thể thực hiện một chức năng theo một giao tiếp chung. 2. Cấu trúc mẫu: 293 Mẫu Composite Trong đó: Component: là một giao tiếp định nghĩa các phương thức cho tất cả các phần của cấu trúc cây. Component có thể được thực thi như một lớp trừu tượng khi bạn cần cung cấp các hành vi cho tất cả các kiểu con. Bình thường, các Component không có các thể hiện, các lớp con hoặc các lớp thực thi của nó, gọi là các nốt, có thể có thể hiện và được sử dụng để tạo nên cấu trúc cây. Composite: là lớp được định nghĩa bởi các thành phần mà nó chứa. Composite chứa một nhóm động các Component, vì vậy nó có các phương thức để thêm vào hoặc loại bổ các thể hiện của Component trong tập các Component của nó. Những phương thức được định nghĩa trong Component được thực thi để thực hiện các hành vi đặc tả cho lớp Composite và để gọi lại phương thức đó trong các nốt của nó. Lớp Composite được gọi là lớp nhánh hay lớp chứa Leaf: là lớp thực thi từ giao tiếp Component. Sự khác nhau giữa lớp Leaf và Composite là lớp Leaf không chứa các tham chiếu đến các Component khác, lớp Leaf 294 đại diện cho mức thấp nhất của cấu trúc cây. Mẫu Composite 3. Tình huống áp dụng Khi có một mô hình thành phần với cấu trúc nhánh – lá, toàn bộ – bộ phận, … Khi cấu trúc có thể có vài mức phức tạp và động Bạn muốn thăm cấu trúc thành phần theo một cách qui chuẩn, sử dụng các thao tác chung thông qua mối quan hệ kế thừa. 4. Ví dụ:  Trở lại ví dụ về dự án, một Project (Composite) có nhiều tác vụ Task (Leaf), ta cần tính tổng thời gian của dự án thông qua thời gian của tất cả các tác vụ 295 Mẫu Decorator 1.Ý nghĩa: Bổ sung trách nhiệm cho đối tượng tại thời điểm thực thi. Đây được xem là sự thay thế hiệu quả cho phương pháp kế thừa trong việc bổ sung trách nhiệm cho đối tượng và mức tác động là ở mức đối tượng thay vì ở mức lớp như phương pháp kế thừa. 2. Cấu trúc mẫu: 296 Mẫu Decorator Trong đó: Component: là một interface chứa các phương thức ảo (ở đây là defaultMethod) ConcreteComponent: là một lớp kế thừa từ Component, cài đặt các phương thức cụ thể (defaultMethod được cài đặt tường minh) Decorator: là một lớp ảo kế thừa từ Component đồng thời cũng chứa 1 thể hiện của Component, phương thức defaultMethod trong Decorator sẽ được thực hiện thông qua thể hiện này. ConcreteDecoratorX: là các lớp kế thừa từ Decorator, khai báo tường minh các phương thức, đặc biệt trong các lớp này khai báo tường minh các “trách nhiệm” cần thêm vào khi run-time 297 Mẫu Decorator 3. Tình huống áp dụng Khi bạn muốn thay đổi động mà không ảnh hưởng đến người dùng, không phụ thuộc vào giới hạn các lớp con. Khi bạn muốn thành phần có thể thêm vào hoặc rút bỏ đi khi hệ thống đang chạy Có một số đặc tính phụ thuộc mà bạn muốn ứng dụng một cách động và bạn muốn kết hợp chúng vào trong một thành phần. 298 4. Ví dụ:  Giả sử trong thư viện có các tài liệu: sách, video… Các loại tài liệu này có các thuộc tính khác nhau, phương thức hiển thị của giao tiếp LibraryItem sẽ hiển thị các thông tin này. Giả sử, ngoài các thông tin thuộc tính trên, đôi khi ta muốn hiển thị độc giả mượn một cuốn sách (chức năng hiển thị độc giả này không phải lúc nào cũng muốn hiển thị), hoặc muốn xem đoạn video(không thường xuyên). 299 Mẫu Façade 1.Ý nghĩa: Cung cấp một giao tiếp hợp nhất của một tập các giao tiếp trong hệ thống con. Façade định nghĩa một giao tiếp mức cao hơn để làm cho hệ thống con dễ sử dụng 2. Cấu trúc mẫu: 300 Mẫu Façade Trong đó: Class1 và Class2 là các lớp đã có trong hệ thống Façade là lớp sử dụng các phương thức của Class1 và Class2 để tạo ra một giao diện mới, thường được sử dụng, đỡ phức tạp hơn khi sử dụng riêng Class1 và Class2 301 Mẫu Façade 3. Tình huống áp dụng Làm cho một hệ thống phức tạp dễ sử dụng hơn bằng cách cung cấp một giao tiếp đơn gian mà không cần loại bỏ các lựa chọn phức tạp Giảm bớt sự ràng buộc giữa client và các hệ thống con. 302 Mẫu Façade 4. Ví dụ:  Giả sử hệ thống cũ đã có các lớp: Địa chỉ, Số điện thoại, Tên tuổi về thông tin của một người, giờ ta muốn quản lý các thông tin trên của một người, ta tận dụng lại hệ thống cũ, xây một lớp Người sử dụng lại các lớp ở trên. 303 Mẫu Flyweight 1.Ý nghĩa: Làm phương tiện dùng chung để quản lý một cách hiệu quả một số lượng lớn các đối tượng nhỏ có các đặc điểm chung, mà các đối tượng nhỏ này lại được sử dụng tuỳ thuộc vào hoàn cảnh, điều kiện ngoài. 304 4.4.6 Mẫu Flyweight 2. Cấu trúc mẫu: Trong đó: o FlyweightFactory: tạo ra và quản lý các đối tượng Flyweight o Flyweight là một giao tiếp định nghĩa các phương thức chuẩn o ConcreteFlyweightX: là các lớp thực thi của Flyweight, các thể hiện của305 các lớp này sẽ được sử dụng tuỳ thuộc vào điều kiện ngoài. Mẫu Flyweight 3. Tình huống áp dụng Ứng dụng sử dụng nhiều đối tượng giống hoặc gần giống nhau Với các đối tượng gần giống nhau, những phần không giống nhau có thể tách rời với các phần giống nhau để cho phép các phần giống nhau có thể chia sẻ Nhóm các đối tượng gần giống nhau có thể được thay thế bởi một đối tượng chia sẻ mà các phần không giống nhau đã được loại bỏ Nếu ứng dụng cần phân biệt các đối tương gần giống nhau trong trạng thái gốc của chúng 306 Mẫu Flyweight 4. Ví dụ: Một ví dụ cổ điển của mẫu flyweight là các kí tự được lưu trong một bộ xử lí văn bản (word processor). Mỗi kí tự đại diện cho một đối tượng mà có dữ liệu là loại font (font face), kích thước font, và các dữ liệu định dạng khác. Bạn có thể tưởng tượng là, với một tài liệu (document) lớn với cấu trúc dữ liệu như thế này thì sẽ bộ xử lí văn bản sẽ khó mà có thể xử lí được. Hơn nữa, vì hầu hết dữ liệu dạng này là lặp lại, phải có một cách để giảm việc lưu giữ này – đó chính là mẫu Flyweight. Mỗi đối tượng kí tự sẽ chứa một tham chiếu đến một đối tượng định dạng riêng rẽ mà chính đối tượng này sẽ chứa các thuộc tính cần thiết. Điều này sẽ giảm một lượng lớn sự lưu giữ bằng cách kết hợp mọi kí tự có định dạng giống nhau trở thành các đối tượng đơn chỉ chứa tham chiếu đến cùng một đối tượng đơn chứa định dạng chung đó. 307 Mẫu Flyweight 308 Mẫu Proxy 1.Ý nghĩa: Đại diện một đối tượng phức tạp bằng một đối tượng đơn giản, vì các mục đích truy xuất, tốc độ và bảo mật 2. Cấu trúc mẫu: 309 Mẫu Proxy Trong đó: o Service: là giao tiếp định nghĩa các phương thức chuẩn cho một dịch vụ nào đó o RealService: là một thực thi của giao tiếp Service, lớp này sẽ khai báo tường minh các phương thức của Service, lớp này xem như thực hiện tốt tất cả các yêu cầu từ Service 310 o Proxy: kế thừa Service và sử dụng đối tượng của RealService Mẫu Proxy 3. Tình huống áp dụng Sử dụng mẫu Proxy khi bạn cần một tham chiếu phức tạp đến một đối tượng thay vì chỉ một cách bình thường Remote proxy – sử dụng khi bạn cần một tham chiếu định vị cho một đối tượng trong không gian địa chỉ(JVM) Virtual proxy – lưu giữ các thông tin thêm vào về một dịch vụ thực vì vậy chúng có thể hoãn lại sự truy xuất vào dịch vụ này Protection proxy – xác thực quyền truy xuất vào một đối tượng thực 311 Mẫu Proxy 4. Ví dụ: Ví dụ lớp Image là một interface định nghĩa các phương thức xử lý ảnh, nó có các lớp con là GIFImage và JPGImage. Theo hướng đối tượng thì thiết kế như thế có vẻ hợp lý, Client chỉ cần sử dụng lớp Image là đủ, còn tuỳ thuộc vào loại ảnh sẽ có các phương thức khác nhau Nhưng trong trường hợp, trên ứng dụng web chẳng hạn, một lúc ta đọc lên hàng trăm ảnh các loại và ta còn muốn xử lý tuỳ vào một điều kiện nào đó (ví dụ chỉ xử lý khi là ảnh JPG hoặc GIF). Nếu ta đặt điều kiện IF Image (sau đó sẽ tùy điều kiện này rồi xử lý riêng) thì không hợp lý, nếu đặt trong Client, nếu mỗi lần cần thay đổi IF ta lại sửa Client => không hợp lý khi Client là một ứng dụng lớn. Ta sử dụng Proxy, lớp ImageProxy chỉ là lớp đại diện cho Image, kế thừa từ Image và sử dụng các lớp GIFImage hay JPGImage. Khi cần thay đổi ta chỉ cần thay đổi trên Proxy mà không cần tác động đến Client và Image. 312 Mẫu Proxy 313 d. NHÓM CÁC MẪU TƯƠNG TÁC- Behavioral Patterns 1. Mục đích chung: mục đích mô tả sự tương tác giữa các đối tượng 314 Mẫu Chain of Responsibility 1. Ý nghĩa: Mẫu này thiết lập một chuỗi bên trong một hệ thống, nơi mà các thông điệp hoặc có thể được thực hiện ở tại một mức nơi mà nó được nhận lần đầu hoặc là được chuyển đến một đối tượng mà có thể thực hiện điều đóTạo một giao diện trung gian để gắn kết vào hệ thống một lớp đối tượng mong muốn nào đó. 2. Cấu trúc mẫu: 315 Mẫu Chain of Responsibility Trong đó: o Handler: là một giao tiếp định nghĩa phương thức sử dụng để chuyển thông điệp qua các lần thực hiện tiếp theo. o ConcreteHandler: là một thực thi của giao tiếp Handler. Nó giữ một tham chiếu đến một Handler tiếp theo. Việc thực thi phương thức handleMessage có thể xác định làm thế nào để thực hiện phương thức và gọi một handlerMethod, chuyển tiếp thông điệp đến cho Handler tiếp theo hoặc kết hợp cả hai 316 Mẫu Chain of Responsibility 3. Tình huống áp dụng Có một nhóm các đối tượng trong một hệ thống có thể đáp ứng tất cả các loại thông điệp giống nhau Các thông điệp phải được thực hiện bởi một vài các đối tượng trong hệ thống Các thông điệp đi theo mô hình “thực hiện – chuyển tiếp”, một vài sự kiện có thể được thực hiện tại mức mà chúng được nhận hoặc tại ra, trong khi số khác phải được chuyển tiếp đến một vài đối tượng khác 317 Mẫu Chain of Responsibility 4. Ví dụ: Hệ thống quản lý thông tin cá nhân có thể được sử dụng để quản lý các dự án như là các liên hệ. Ta hình dung một cấu trúc cây như sau; đỉnh là một dự án, các đỉnh con là các tác vụ của dự án đó, và cứ như vậy, mỗi đỉnh con tác vụ lại có một tập các đỉnh con tác vụ khác. Để quản lý cấu trúc này ta thực hiện như sau: -Ở mỗi đỉnh ta lưu các thông tin như sau: tên tác vụ, đỉnh cha, tập các đỉnh con -Ta xét thông điệp sau: duyệt từ đỉnh gốc (project cở sở) in ra các thông tin -Như vậy với thông điệp này, việc in thông tin ở một đỉnh là chưa đủ, ta phải chuyển tiếp đến in thông tin các đỉnh con của đỉnh gốc và chuyển tiếp cho đến khi không còn đỉnh con thì mới dừng 318 Mẫu Chain of Responsibility 319 Mẫu Command 1. Ý nghĩa: Gói một mệnh lệnh vào trong một đối tượng mà nó có thể được lưu trữ, chuyển vào các phương thức và trả về một vài đối tượng khác. 2. Cấu trúc mẫu: Trong đó: o Command: là một giao tiếp định nghĩa các phương thức cho Invoker sử dụng o Invoker: lớp này thực hiện các phương thức của đối tượng Command o Receiver: là đích đến của Command và là đối tượng thực hiện hoàn tất yêu cầu, nó có tất cả các thông tin cần thiết để thực hiện điều này o ConcreteCommand: là một thực thi của giao tiếp Command. Nó lưu giữa một tham chiếu Receiver mong muốn 320 Mẫu Command Luồng thực thi của mẫu Command như sau: 321 Mẫu Command Client gửi yêu cầu đến GUI của ứng dụng Ứng dụng khởi tạo một đối tượng Command thích hợp cho yêu cầu đó (đối tượng này sẽ là các ConcreteCommand) Sau đó ứng dụng gọi phương thức executeCommand() với tham số là đối tượng Command vừa khởi tạo Invoker khi được gọi thông qua phương thức executeCommand() sẽ thực hiện gọi phương thức execute() của đối tượng Command tham số Đối tượng Command này sẽ gọi tiếp phương thức doAction() của thành phần Receiver của nó, được khởi tạo từ đầu, doAction() chính là phương thức chính để hoàn tất yêu cầu của Client 322 Mẫu Command 3. Tình huống áp dụng Hỗ trợ undo, logging hoặc transaction Thực hiện hàng đợi lệnh và thực hiện lệnh tại các thời điểm khác nhau Hạn chế sự chặt chẽ của yêu cầu với đối tượng thực hiện hoàn tất yêu cầu đó 323 Mẫu Interpreter 1. Ý nghĩa:  Ý tưởng chính của Interpreter là triển khai ngôn ngữ máy tính đặc tả để giải quyết nhanh một lớp vấn đề được định nghĩa. Ngôn ngữ đặc tả thường làm cho vấn đề được giải quyết nhanh hơn ngôn ngữ thông thường từ một cho đến vài trăm lần.  Ý tưởng tương tự như vậy biểu diễn các biểu thức tính toán theo cú pháp Ba Lan 2. Cấu trúc mẫu: 324 Mẫu Command Trong đó: Expression: là một giao tiếp mà thông qua nó, client tương tác với các biểu thức o TerminalExpression: là một thực thi của giao tiếp Expression, đại diện cho các nốt cuối trong cây cú pháp o NonterminalExpression: là một thực thi khác của giao tiếp Expression, đại diện cho các nút chưa kết thúc trong cấu trúc của cây cú pháp. Nó lưu trữ một tham chiếu đến Expression và triệu gọi phương thức diễn giải cho mỗi phần tử con o Context: chứa thông tin cần thiết cho một vài vị trí trong khi diễn giải. Nó có thể phục vụ như một kênh truyền thông cho các thể hiện của Expression o Client: hoặc là xây dựng hoặc là nhận một thể hiện của cây cú pháp ảo. Cây cú pháp này bao gồm các thể hiện của TerminalExpression và NoterminalExpression để tạo nên câu đặc tả. Client triệu gọi các phương thức 325 diễn giải với ngữ cảnh thích hợp khi cần thiết Mẫu Interpreter 3. Tình huống áp dụng Có một ngôn ngữ đơn giản để diễn giải vấn đề Các vấn đề lặp lại có thể được diễn giải nhanh bằng ngôn ngữ đó 4. Ví dụ: Xét biểu thức 5 + 3 x 3 + 6, với bài tóan này ta có thể chia thành các bài các bài tóan nhỏ hơn -Tính 3 x 3 = a -Sau đó tính 5 + a = b -Sau đó tính b + 6 Ta biểu diễn bài tóan thành cấu trúc cây và duyệt cây theo Ba Lan 326 Mẫu Interpreter 327 References 1. http://www.uml.org.cn/c++/pdf/DesignPatterns.pdf 2. http://duydo.com/design-patterns-l%E1%BA%ADp-trinhvien-c%E1%BA%A7n-ph%E1%BA%A3i-bi%E1%BA%BFt/ Giới thiệu các mẫu thiết kế hướng đối tượng (Design Pattern) 3. http://duriangroup.wordpress.com/2007/10/27/gi%E1%BB% 9Bi-thi%E1%BB%87u-cac-m%E1%BA%AButhi%E1%BA%BFt-k%E1%BA%BFh%C6%B0%E1%BB%9Bng-d%E1%BB%91it%C6%B0%E1%BB%A3ng-design-pattern/ 328 HẾT CHƯƠNG 3 329