Phân tích thiết kế hệ thống thông tin - Chương VI: Thiết kế mô hình hệ thống thông tin tổng thể

Nội dung text: Phân tích thiết kế hệ thống thông tin - Chương VI: Thiết kế mô hình hệ thống thông tin tổng thể

1. Giáo trình: Phân tích & thiết kế HTTT. CHƯƠNG VI: THIẾT KẾ MÔ HÌNH HỆ THỐNG THÔNG TIN TỔNG THỂ 1. MÔ HÌNH TỔNG THỂ Phần này ứng với giai đoạn nghiên cứu khả thi trong quá trình xây dựng một hệ thống thông tin. Sau khi phân tích hệ thống (khảo sát, điều tra, mô tả hệ thống) chúng ta đã xây dựng các mô hình ở mức quan niệm và logic, nhưng chưa đề cập đến việc hệ thống sẽ vận hành như thế nào. Bước xây dựng mô hình tổng thể cho hệ thống là phải làm rõ điều đó. Chúng được thể hiện trên các mặt sau: • Tổ chức hệ thống máy tính. • Lựa chọn phần mềm, tổ chức lưu trữ, trao đổi, sao lưu dữ liệu. • Bố trí phần mềm, dự kiến phân quyền cho các nhóm người dùng. 2. TỔ CHỨC HỆ THỐNG MÁY TÍNH Một số mô hình tổng thể tổ chức hệ thống máy tính: 2.1. Hệ thống được tổ chức thực thi trên 01 máy đơn Đây là mô hình đơn giản nhất. Nó có ưu điểm là chi phí đầu tư cho phần cứng thấp (chỉ cần 01 máy). Nhược điểm là hình thức này chỉ thích hợp với những hệ thống của đơn thể nhỏ, không đòi hỏi phải trao đổi, truyền thông dữ liệu trong nội bộ hệ thống. Nếu phạm vi của vấn đề và bản chất của bài toán phù hợp với hình thức tổ chức này thì đây là sự lưa chọn tối ưu. Những hệ thống thông tin trước đây (thập niên 80, 90 ở thế kỷ trước). 2.2. Hệ thống được tổ chức thực thi rời rạc trên nhiếu máy đơn Đây là mô hình được triển khai trên nhiều máy đơn nhưng các máy này không cần kết nối mạng để chia sẽ, trao đổi dữ liệu thường xuyên. Đặc điểm của phương pháp tổ chức này là chi phí đầu tư không cao (bằng tổng chi phí đầu tư của tất cả các máy cộng lại). Nó thích hợp với những bài toán mà khi giải quyết không cần chia sẽ, trao đổi dữ liệu. Nhược điểm là khi cần tổng hợp kết quả thì đòi hỏi phải nối kết dữ liệu. Thí dụ hệ thống dữ liệu tuyển sinh đại học trong những năm vừa qua được tổ chức theo mô hình này. 2.3. Hệ thống được tổ chức thực thi trên một mạng cục bộ Đây là mô hình được triển khai trên nhiều máy được kết nối với nhau trong một mạng cục bộ. Có thể trong mạng này có một máy chủ (SERVER) và nhiều máy trạm (CLIENTS) hay các máy tính gồm các máy nối kết ngang hàng. Đặc điểm của mô hình này là chi phí đầu tư không cao, thích hợp với những tổ chức có nhiều đơn vị có vị trí địa lý gần nhau, có thể bảo đảm tính bảo mật của dữ liệu đối với môi trường bên ngoài. Nếu hệ thống tổ chức lưu trữ tất cả các dữ liệu trên SERVER, các máy trạm chỉ thực thi các chức năng thì có thể chia sẽ những dữ liệu dùng chung. Nhược điểm của mô hình này là khó khăn trong việc bảo đảm tính toàn vẹn cho dữ liệu khi nhiều người cùng thao tác trên cùng một cơ sở dữ liệu. Những hệ thống triển khai trên những tổ chức mà có nhiều đơn vị có khoảng cách địa lý xa, khi trao đổi dữ liệu với nhau có thể gặp khó khăn nhất là khi cần tìm kiếm, truy xuất thông tin trên nhiều nguồn dữ liệu, phạm vi tìm kiếm lớn (dữ liệu nhiều) có thể ảnh hưởng tới những thao tác thông thường. Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 95
2. Giáo trình: Phân tích & thiết kế HTTT. 2.4. Hệ thống được tổ chức thực thi trên một mạng diện rộng. Đây là mô hình được triển khai trên nhiều máy được kết nối với nhau trong một mạng diện rộng. Các máy tính trong hệ thống có thể kết nối tương tác với nhau. Với mô hình này dữ liệu của hệ thống thông tin có thể bố trí phân mảnh ở nhiều nơi. Có một số phương pháp phân mảnh dữ liệu: theo bề ngang, theo chiều dọc hay nhân bản nhiều nơi. Mô hình tổ chức này thích hợp cho những hệ thống thông tin triển khai trên diện rộng. Tuy nhiên chi phí đầu tư cho mô hình tổ chức này cao, việc tham khảo những dữ liệu dùng chung sẽ gặp khó khăn, nếu không sẽ vi phạm tính toàn vẹn và nhất quán của dữ liệu nếu tổ chức nhân bản nhiều nơi. Mô hình này có thể thích hợp với những hệ thống thông tin mà những dữ liệu dùng chung không (hoặc ít) biến động. Việc lựa chọn mô hình tổng thể phải dựa vào: • Bản chất của hệ thống, yêu cầu của tổ chức: hệ thống thích hợp với mô hình tổng thể nào. Nếu hệ thống phức tạp nhưng chỉ cần triển khai trên 01 máy hay một số máy không cần phân tán thì chẳng nên áp dụng trên một mô hình khác làm gì. • Quy mô của tổ chức như thế nào? Cơ cấu của tổ chức có bao gồm nhiều đơn vị thành phần hay không? Các đơn vị có cần truyền thông thông tin với nhau hay không? khoảng cách địa lý giữa các đơn vị có xa nhau hay không? • Tình hình tài chính, thiết bị, phần cứng, phần mềm. Giải pháp lựa chọn mô hình tổng thể nào cũng phải dựa trên việc đầu tư tài chính, thiết bị, phần cứng cũng như phần mềm hệ thống (hệ điều hành, hệ quản trị cơ sở dữ liệu). Việc lựa chọn mô hình cũng phải dựa trên cơ sở tiết kiệm và định hướng chắc chắn giải quyết được vấn đề. Chủng loại thiết bị, tính năng (đáp ứng tính khả thi về kỷ thuật), giá cả và thời hạn đáp ứng cũng cần đề cập khi quyết định. • Trình độ tin học của nhóm thực hiện dự án. Khi quyết định lựa chọn một mô hình tổng thể cũng cần xem xét đội ngũ tham gia, họ có thế mạnh gì, đã thành thạo với hệ thống thông tin này hay một hệ thống tương tự chưa, có khả năng làm chủ với ngôn ngữ lập trình hay hệ quản trị cơ sở dữ liệu nào? • Hiệu quả kinh tế mang lại, nghĩa là phải ước lượng được trả lại đầu tư. • Trong thực tế người ta thường chọn một giải pháp lai giữa các mô hình trên xuất phát từ yêu cầu thực tiễn. Trong thực tế, thường khi triển khai một hệ thống thông tin thì hệ thống máy tính đã tồn tại. Nhóm dự án thường chỉ có việc lập kế hoạch để tổ chức lại, có thể mua sắm, trang bị thêm, thay đổi vị trí lắp đặt, kết nối. Nếu phải trang bị lắp đặt mới thì đây là cơ sở để lập các hợp đồng mua sắm cung cấp thiết bị. Chủng loại thiết bị: những máy móc nào, đảm bảo những yêu cầu kỷ thuật nào cần phải sắm và thời điểm đáp ứng cũng phải được đề cập trong hợp đồng. Những tiêu chuẩn thường đặt ra là: dung lượng bộ nhớ ngoài, tốc độ xử lý, tốc độ đường truyền, bảo đảm tính an toàn cho dữ liệu. Nếu việc cung cấp thiết bị không kịp thời sẽ làm chậm tiến độ của việc thực hiện dự án. Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 96
3. Giáo trình: Phân tích & thiết kế HTTT. 3. SỰ LỰA CHỌN PHẦN MỀM, TỔ CHỨC LƯU TRỮ, TRAO ĐỔI, SAO LƯU DỮ LIỆU. 3.1. Lựa chọn phần mềm hệ thống Khi triển khai một hệ thống thông tin không phải nhóm thực hiện dự án tiến hành làm tất cả mọi thứ. Hệ điều hành, hệ quản trị cơ sở dữ liệu và các công cụ phát triển phần mềm thường phải mua. Đây là giai đoạn thiết kế khả thi nên những thứ trên cũng phải đưa vào kế hoạch thực hiện của dự án. Nó là cơ sở cho việc mua sắm phần mềm nhất là khi vấn đề bản quyền phần mềm và sở hữu trí tuệ đang được đặt ra nghiêm ngặt. Ngày nay các trường học và cơ quan công quyền được khuyến khích sử dụng các phần mềm nguồn mở vì không phải bỏ ra chi phí cho việc mua phần mềm, tuy nhiên các công cụ hỗ trợ trong các phần mềm nguồn mở cho việc phát triển phần mềm bị hạn chế. Việc lựa chọn phần mềm cũng phụ thuộc nhiều yếu tố như: bản chất bài toán, các yêu cầu của người dùng, yêu cầu kỷ thuật, tầm vóc hệ thống và phạm vi triển khai, sự đáp ứng về mặt tài chính có thể bỏ ra cho việc mua phần mềm. 3.2. Tổ chức lưu trữ Việc tổ chức dữ liệu phụ thuộc vào bản chất của hệ thống và việc tổ chức hệ thông máy tính đã được đề cập ở trên. Một số mô hình tổ chức dữ liệu: Tập trung: tất cả dữ liệu được lưu trữ ở một máy (thường là SERVER). Phân tán: dữ liệu được tổ chức lưu trữ ở nhiều máy. Có 3 hình thức tổ chức phân tán như sau: ƒ Phân mảnh chiều ngang: cấu trúc dữ liệu trên các máy giống nhau, mỗi bộ (của một bảng) chỉ được lưu ở một máy nào đó. Thông thường việc phân mảnh này phải theo một hoặc một vài tiêu chí nào đó, chẳng hạn trong quản lý mua bán hàng hoá thì theo các máy bố trí tại các cửa hàng, trong hệ thống tuyển sinh thì dữ liệu được phân chia theo từng ban tuyển sinh, từng trường Đại hộc Cao đẳng tuỳ theo giai đoạn. ƒ Phân mảnh theo chiều dọc, mỗi máy chỉ chứa một số thuộc tính (cột) nào đó trong các bảng dữ liệu. Dĩ nhiên là có những thuộc tính được lặp ở nhiều máy (các thuộc tính làm khoá). Thí dụ trong một cơ quan, dữ liệu nhân sự có thể được tổ chức phân mảnh theo kiểu này. Phòng tổ chức cán bộ lưu trữ các thông tin liên quan tới lý lịch cá nhân, phòng giáo vụ sẽ lưu trữ những thông tin liên quan tời việc giảng dạy, phòng tài vụ lưu trữ những thông tin liên quan tới việc thu nhập (lương, thưởng, tạm ứng, thanh toán ). ƒ Dữ liệu được nhân bản trên nhiều máy. Ở đây không phải nhân bản để bảo đảm tính an toàn của dữ liệu mà do phải thường xuyên quan tâm tới toàn bộ dữ liệu ở nhiều máy. Chẳng hạn hệ thống các đại lý bán vé máy bay, khi một hành khách vừa được chấp nhận một chổ trên một chuyến bay, thì tất cả các đại lý khách phải được biết thông tin về sự đặt chổ này để tránh việc đụng độ. Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 97
4. Giáo trình: Phân tích & thiết kế HTTT. 3.3. Trao đổi dữ liệu Khi một hệ thống được triển khai phân tán trên diện rộng, việc trao đổi dữ liệu giữa các trạm làm việc với nhau là một yêu cầu tất yếu. Thí dụ: trong hệ thống quản lý mua bán hàng, các cửa hàng cần những thông tin về các phiếu thu, chi cho cửa hàng mình để theo dõi công nợ; bộ phận kế toán tổng hợp cần các dữ liệu về hàng hoá của tất cả các cửa hàng và dữ liệu thu chi từ phòng tài vụ. Ngay các cửa hàng có khi cũng cần trao đổi dữ liệu với nhau, chẳng hạn một phiếu xuất chuyển kho từ một cửa hàng đến một cửa hàng khách, phải được cửa hàng thứ hai nhận được để theo dõi và có thể tiết kiệm trong thao tác, tránh những sai sót do việc nạp lại dữ liệu. Đối với những hệ thống này việc bảo đảm tính nhất quán và tích hợp dữ liệu là rất quan trọng. 3.4. Sao lưu dữ liệu Những dữ liệu quan trọng luôn bị đe doạ từ việc truy cập bất hợp pháp đến việc làm hư hỏng bộ phận hay toàn bộ. Do đó việc sao lưu dữ liệu là một công việc hết sức cần thiết. Những dữ liệu quan trọng nếu có điều kiện cần phải được sao lưu ở vị trí an toàn đề phòng những sự cố ngoài dự kiến như hoả hoạn, khủng bố. Cần nghiên cứu toàn diện các vấn đề, nhất là đối với hệ thống lớn. 4. PHÂN BỐ PHẦN MỀM, DỰ KIẾN PHÂN QUYỀN NHÓM NGƯỜI DÙNG 4.1. Phân bố phần mềm. Một hệ thống thông tin bao giờ cũng tồn tại một cơ sở dữ liệu và một hệ thống phần mềm mà thông qua giao diện của nó người dùng tương tác với hệ thống. Hệ thống phần mềm thường gồm nhiều chức năng thường được tổ chức thành các thủ tục và có thể được phân hoạch thành các khối chức năng hoặc gộp chung lại trong một thể thống nhất. Khi hệ thống được triển khai người ta có nhiều cách phân bố phần mềm. Cách thứ nhất là tích hợp tất cả các chức năng vào một chương trình, cài đặt duy nhất trên SERVER, các máy trạm chỉ cần kết nối và chạy (thông qua một shortcut). Người dùng đăng nhập vào hệ thống và nếu được phép thực thi thì dựa vào chức năng phân quyền mà chỉ những chức năng được phép sử dụng họ mới được phép thao tác và cũng chỉ trên phạm vi mà họ được phép mà thôi. Cách này thuận lợi khi nâng cấp phần mềm, chỉ cần thay chương trình trên SERVER là được. Tuy nhiên khi thực thi, chương trình thường xử lý chậm do phải tải cả chương trình và dữ liệu về máy trạm. Cách thứ hai là tuỳ theo thẩm quyền của người dùng mà cài chức năng vửa đủ trên máy của họ. Thí dụ trong hệ thống quản lý mua bán hàng, tại các cửa hàng chỉ cài đặt các chức năng: lập phiếu nhập kho, lập hoá đơn bán hàng, lập báo cáo tồn kho, thẻ kho, tình hình kinh doanh bán hàng, truyền dữ liệu mua bán hàng cho bộ phận kế toán tổng hợp của chỉ cửa hàng đó; ở phòng tài vụ chỉ cài các chức năng lập phiếu thu, phiếu chi, theo dõi tồn quỹ, truyền dữ liệu thu chi cho bộ phận kế toán tổng hợp Cách phân bố này phụ thuộc vào từng máy, nhóm người dùng có thể khác không thể thực thi trên máy này. Trong lập trình những module đa nhiệm không được tận dụng triệt để, việc nâng cấp phần mềm sẽ gặp khó khăn vì phải cài đặt nhiều nơi. Cách thứ ba là do sự phát triển của các ngôn ngữ lập trình và các công cụ triển khai phần mềm, những dự án lớn có thể gồm nhiều phân hệ, mỗi một phân hệ thường do Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 98
5. Giáo trình: Phân tích & thiết kế HTTT. một hoặc một nhóm nào đó phát triển phần mềm. Việc nâng cấp các chức năng phần mềm là điều thường xảy ra khi mà yêu cầu của hệ thống và cả của người dùng thay đổi hoặc phát sinh thêm, người ta không cần biên dịch lại toàn bộ phần mềm mà chỉ cần thay đổi phần mềm liên quan mà thôi (Dynamic-link library - DLL). Đặc tính này tạo nên sự thuận lợi khi bảo trì và phát triển phần mềm. 4.2. Vấn đề người dùng Vai trò của (nhóm) người dùng Trong một hệ thống thông tin, thẩm quyền trên dữ liệu cũng được quy định. Dữ liệu nào có thể phổ biến rộng rãi cho mọi người, dữ liệu nào cần được dùng chung, dữ liệu nào được chia sẽ, chia sẻ cho những nhóm người dùng nào, dữ liệu nào dùng riêng, cho mục đích nào, dữ liệu nào cần bảo mật, bảo mật tới mức nào. ai tạo và cập nhật loại dữ liệu nào, trên phạm vi nào, ai được xem loại kết xuất thông tin nào ? Thông thường sau khi hệ thống đã làm rõ các chức năng (thí dụ mỗi ô xử lý trong lưu đồ dòng dữ liệu ứng với một chức năng trong thực đơn hệ thống) thì phân quyền theo chúng: ai được phép thực thi chức năng nào trên phạm vi nào thông qua một thủ tục (form) phân quyền. Người nào không được thực thi chức năng nào thì sau khi đăng nhập được vào hệ thống các chức năng đó bị vô hiệu hoá (có thể làm mờ đi, không thao tác được). Số lượng (nhóm) người dùng Số lượng người dùng cũng là vấn đề cần quan tâm vì nó có thể liên quan tới việc mua sắm hệ quản trị cơ sở dữ liệu. Giá của hệ quản trị cơ sở dữ liệu còn phụ thuộc vào số người dùng mà mình đăng ký để mua. Đặc biệt là nhóm những người thao tác với hệ thống (cập nhật dữ liệu). Số lượng này phải được tính đến nhất là những hệ thống mà việc cập nhật dữ liệu phức tạp do cùng một lúc phải tham khảo nhiều loại dữ liệu, nhiều tình huống ứng xử khi nhiều người cùng cập nhật mà việc giải quyết đụng độ sẽ gặp khó khăn. Kết luận: bản thiết kế mô hình tổng có thể được trình bày cùng các phương án để tăng thêm sức thuyết phục trong việc lựa chọn giải pháp. Việc lựa chọn mô hình tổng thể có vai trò quyết định cho sự thành công của dự án. Công việc này nên giao cho những người có kinh nghiệm, có khả năng vì nó phải đáp ứng một các hợp lý các yêu cầu trên. Có thể trước khi lựa chọn nên đưa ra một số giải pháp để tiện việc so sánh, rồi lựa chọn một giải pháp phù hợp chấp nhận được giữa các bên. Ý nghĩa của giai đoạn này là cơ sở cho việc lập dự trù kinh phí cũng như lập kế hoạch triển khai dự án. Trong nhiều trường hợp có khi phải sắp xếp lại cơ cấu tổ chức cho phù hợp với hệ thống thông tin mới. Kế hoạch và tiến độ thực hiện cho việc xây dựng một hệ thống thông tin hợp lý cũng là một vấn đề quan trọng. Công việc nào cần phải tiến hành trước, công việc nào sau, người hay nhóm người nào thực hiện và thực hiện trong bao lâu, sử dụng tài nguyên gì 5. CÁC VÍ DỤ MINH HỌA 5.1. Thí dụ 1: Hệ thống tuyển sinh đại học toàn quốc Hiện tại hệ thống này gồm nhiều giai đoạn: Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 99
6. Giáo trình: Phân tích & thiết kế HTTT. Giai đoạn 1: đăng ký dự thi, mỗi đơn vị (thường là Ban tuyển sinh tỉnh / thành phố hay các trường phổ thông trung học, các trường đại học, ) chịu trách nhiệm ghi nhận sự đăng ký dự thi từ hồ sơ đăng ký dự thi của thí sinh thuộc khu vực mà thí sinh có thể nộp hồ sơ. Nghĩa là việc đăng ký thường được triển khai trên các máy riêng rẽ. Sau đó dữ liệu đăng ký đó được tách ra theo từng trường Đại học mà thí sinh đăng ký nguyện vọng 1. Giai đoạn 2: Mỗi trường Đại học hoặc cao đẳng ghép nối dữ liệu từ các đơn vị đăng ký dự thi để xử lý cho riêng mình từ khâu tạo số báo danh, sắp xếp phòng thi, nạp điểm thi đến xét tuyển. Nghĩa là giai đoạn này cũng làm riêng mỗi trường thực hiện trên một (hoặc một số) máy độc lập do tính chất bảo mật của dữ liệu. Sau khi chấm thi xong, các trường Đại học tập trung dữ liệu, bàn giao cho Bộ Giáo dục Đào tạo. Giai đoạn 3: Sau khi Bộ Giáo dục Đào tạo nhận đầy đủ dữ liệu về kết quả thi tuyển sinh từ tất cả các trường Đại học gửi về thì tập hợp lại sau đó để tách dữ liệu thí sinh đăng ký nguyện vọng 2 và bàn giao cho từng trường. Bởi vì thí sinh đăng ký nguyện vọng 1 của trường này có thể đăng ký nguyện vọng 2 vào bất kỳ một trường nào đó, thậm chí vào một ngành khác của chính trường đó cho nên chỉ có Bộ Giáo dục Đào tạo mới có chức năng và chịu trách nhiệm tập hợp và phân phối dữ liệu này. Giai đoạn 4: Các trường Đại học nhận kết quả dự thi của các thí sinh có đăng ký nguyện vọng 2 từ Bộ Giáo dục Đào tạo gửi về để mỗi trường xét tiếp. Do tính bảo mật của thông tin nên việc bàn giao dữ liệu được thực hiện bằng các đĩa CDROM chống ghi và có ký nhận của từng bên. Hệ thống tuyển sinh đại học là một hệ thống có quy mô lớn, được thực hiện hàng năm theo kỳ tuyển sinh và cũng do tính đặc thù (bảo mật đặc biệt) nên được tổ chức thực hiện như vậy. Mỗi thành phần tham gia (các đơn vị đăng ký, các trường Đại học và Bộ Giáo dục Đào tạo) tuỳ theo chức năng của mình trong hệ thống tuyển sinh mà có những xử lý riêng. Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 100
7. Giáo trình: Phân tích & thiết kế HTTT. c ọ Các i h đơ đạ BỘ GIÁO DỤC n v ng VÀ ĐÀO TẠO ị ườ đă ng ký d Các tr ự thi MÔ HÌNH HỆ THỐNG TUYỂN SINH ĐẠI HỌC 5.2. Thí dụ 2: Hệ thống thông tin kế toán Hệ thống thông tin kế toán tại một công ty hoặc xí nghiệp nào đó. Thông thường người ta lựa chọn mô hình tổng hợp. Nếu tổ chức có nhiều đơn vị với vị trí địa lý gần nhau (khoảng cách thường không quá 100 m) người ta lựa chọn mô hình mạng cục bộ vì nó thích hợp. Nếu tổ chức có những đơn vị mà khoảng cách tương đối xa, việc truy xuất dữ liệu trực tiếp phải thông qua các hệ thống máy tính gắn modem thì họ vừa dùng một mạng cục bộ cho những đơn vị gần và dữ liệu phân mảnh rời rạc cho những đơn vị có khoảng cách xa. Khi cần kết nối tổng hợp thì tập trung dữ liệu về server hay truyền cho các đơn vị để xử lý riêng. Dĩ nhiên giải pháp này gặp khó khăn trong việc chia sẻ dữ liệu dùng chung (như khách hàng, mặt hàng) mà loại dữ liệu này thường phải bổ sung thêm nên có những cơ chế quản lý hành chánh kèm theo để giải quyết sự bất cập này. Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 101
8. Giáo trình: Phân tích & thiết kế HTTT. CHƯƠNG VII: THIẾT KẾ THÀNH PHẦN DỮ LIỆU 1. CÁC NGUYÊN TẮC CƠ BẢN 1.1. Nguyên tắc 1: Nguyên tắc cơ bản để thiết kế thành phần dữ liệu là xuất phát từ mô hình thực thể - kết hợp. Việc bảo đảm một mô hình thực thể – kết hợp hợp lý là điều căn bản nhất. Việc tuân thủ nguyên tắc này bảo đảm có một cơ sở dữ liệu chuẩn cho hệ thống thông tin. Nhiều HTTT do khi xây dựng không tuân thủ nguyên tắc này làm cho dữ liệu thiếu nhất quán dẫn đến sai sót trong xử lý. 1.2. Nguyên tắc 2: tính khả thi. Nguyên tắc này là phải thiết kế thành phần dữ liệu như thế nào để hệ thống xử lý đơn giản, dễ dàng và thuận tiện đáp ứng mọi yêu cầu khai thác, dễ mở rộng và dễ bảo trì. Muốn vậy phải phát hiện những ràng buộc tiềm ẩn bên trong hệ thống. Trong nhiều trường hợp cần thiết chúng ta có thể tạo sự dư thừa dữ liệu, điều này thường phát sinh thêm các ràng buộc toàn vẹn mới nhưng sẽ thuận lợi trong xử lý. 2. MỘT SỐ PHƯƠNG PHÁP THIẾT KẾ Phương pháp cổ điển: Sau khi có mô hình luận lý về dữ liệu, chúng ta có được một tập hợp các quan hệ cùng những ràng buộc toàn vẹn giữa chúng. Về mặt nguyên tắc nếu dùng một hệ cơ sở dữ liệu, chúng ta có thể thiết kế và tổ chức một cơ sở dữ liệu ứng với chúng. Khi cài đặt chúng ta cần chuyển các khái niệm liên quan: quan hệ -> bảng, thuộc tính -> cột của bảng, lựa chọn kiểu, độ rộng, lựa chọn khóa và các ràng buộc dữ liệu cho các thuộc tính. Phương pháp sử dụng các công cụ tin học để chuyển từ mô hình mức logic sang mô hình mức vật lý. Hiện nay có rất nhiều công cụ: ERWIN, POWER DESIGNER, DESIGNER 2000 ORACLE, cho phép chuyển từ mô hình cải tiến mô hình thực thể - kết hợp thành cơ sở dữ liệu mức vật lý trong các hệ cơ sở dữ liệu phổ biến như ACCESS, SQL SEVER, DB2 hay ORACLE Trong phần phụ lục chúng tôi có giới thiệu 2 công cụ ERWIN và POWER DESIGNER để người đọc có thể tham khảo và ứng dụng. 3. MỘT SỐ VẤN ĐỀ CẦN QUAN TÂM KHI THIẾT KẾ CSDL Để có một cơ sở dữ liệu hợp lý, khi thiết kế chúng ta phải cần quan tâm đến những vấn đề sau: 3.1. Phân loại dữ liệu Tùy theo từng hệ thống thông tin có nhiều cách phân loại dữ liệu (mỗi loại dữ liệu có những đặc tính riêng) thành các nhóm để tổ chức lưu trữ, dễ dàng trong quản lý. Có thể phân hoạch theo tính chất của dữ liệu thành một số nhóm như sau: Dữ liệu thường trực (hay dữ liệu cơ sở):dữ liệu dùng làm cơ sở cho những dữ liệu khác. Dữ liệu này thường là những đặc tính cơ bản của các lớp đối tượng trong thế giới thực, không biến đổi hay nói cách khác là rất ít biến đổi theo thời gian. Trong hệ Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 102
9. Giáo trình: Phân tích & thiết kế HTTT. thống thông tin chúng tồn tại vĩnh cửu và không thay đổi giá trị. Loại dữ liệu này chỉ có thể bổ sung (thêm bộ hay thêm thuộc tính, ví dụ môn học) không nên thay đổi giá trị, đặc biệt là không được xóa). Thí dụ những dữ liệu về con người (họ tên, ngày sinh, phái, địa chỉ, thể hiện dưới nhiều dạng như: học sinh, giáo viên, khách hàng, Đồ vật (tên, đơn vị tính) thể hiện dưới nhiều dạng như: tài sản, hàng hóa, sản phẩm. Dữ liệu gốc: thường thuộc loại dữ liệu lý lịch, dữ liệu lịch sử, hoặc dữ liệu tình trạng - lưu những giá trị xảy ra theo thời gian, không gian. Dữ liệu này phát sinh với tốc độ ngày càng nhanh nên phải có cách thức lưu trữ hoặc xử lý thích hợp. Căn cứ vào thực tế để lựa chọn cách thức tổ chức dữ liệu. Tổ chức tập trung hay phân tán. Nếu tổ chức tập trung thì có bảo đảm tính an toàn của dữ liệu không? Có biện pháp phòng hờ nào? Có thể sao chép dữ liệu gốc không còn thường dùng ra hoặc phân mảnh dữ liệu theo định kỳ hay theo tính chất khác nào đó (theo trạm làm việc chẳng hạn) để lưu trữ để hệ thống hoạt động hiệu quả và bảo đảm tính an toàn của dữ liệu. Để kết xuất thông tin nhiều khi cần những loại dữ liệu trung gian khác. Chẳng hạn: dữ liệu luân chuyển cho dữ liệu khác (tháng sau, kỳ sau) hay tính toán ra những dữ liệu khác. Dữ liệu tạm thời: chỉ dùng trong một thời gian nào đó, khi không cần có thể xóa đi. 3.2. Thiết kế các bảng trong CSDL • Định danh (tên cơ sở dữ liệu, tên bảng, tên thuộc tính, ). Việc đặt tên các đối tựợng một cách có hệ thống sẽ đơn giản trong việc bảo trì, nhất là khi làm việc theo nhóm. • Định kiểu cho mỗi thuộc tính. Có những thuộc tính qui định kiểu, nhưng có những thuộc tính chúng ta có thể lựa chọn kiểu để phù hợp với thực tế (ngày sinh) và thuận tiện trong xử lý sau này. • Xác định độ rộng cho mỗi thuộc tính (độ rộng vừa đủ, chú ý trường hợp đặc biệt). • Xác định khóa chính, các chỉ mục, các quy tắc kiểm tra giá trị, thuộc tính nào không thể hay có thể mang giá trị rỗng. • Mã hóa dữ liệu: thường dùng làm giá trị cho thuộc tính chỉ định của một bảng nào đó (nó thường là khóa chính). Vì vậy khi tiến hành mã hóa phải có sự phân loại để dễ dàng cho việc truy xuất và cập nhật sau này. Nên dùng dữ liệu kiểu ký tự số để mã hóa, trừ những trường hợp đặc biệt mới dùng ký tự phi số vì cần phải kiểm tra giá trị mã là chữ hoa hoặc chữ thường 3.3. Nơi lưu trữ dữ liệu Nơi lưu trữ và tiến hành xử lý để quyết định thiết kế lưu trữ tập trung hay phân tán. Nếu phân tán thì việc trao đổi, chia sẻ tài nguyên theo cách thức nào? Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 103
10. Giáo trình: Phân tích & thiết kế HTTT. 3.4. Cách thức trao đổi và truyền dữ liệu giữa các trạm làm việc Thí dụ: Trong hệ thống quản lý mua bán hàng mà chúng đã đã đề cập, khi chuyển sang Mô hình CSDL quan hệ ta có các quan hệ: HANGHOA(MAHANG, TENHANG, DVT) PHIEUNHAP(STT_PN, NGAY_NHAP, THUE_NHAP, MACH, MAKHACH, MA_NV) PHIEUCHI(STT_PC, NGAYCHI, SOTIEN, STT_PN) NHAP(STT_PN, MAHANG, SL_NHAP, DG_NHAP) HOADON(STT_HD, NGAYLAP, THUESUAT, NGAY_THANH, MACH, MAKHACH, S0_SERI) QUYEN_HD(SO_SERI) CUAHANG(MACH, TENCUAHANG, DCHI_CH) KHACHHANG(MAKHACH, HOTEN_KH, DCHI, MASO_THUE) GOMCO(STT_HD, MAHANG, SL,DG) NHANVIEN(MA_NV, HOTEN_NV, DCHI_NV) PHIEUTHU(STT_PT, NGAYTHU, SOTIEN, STT_HD) Ràng buộc tham chiếu: HOADON (SO_SERI) → QUYEN_HD(SO_SERI) HOADON (MACH) → CUAHANG(MACH) HOADON (MAKHACH) → KHACHHANG(MAKHACH) GOMCO(STT_HD) → HOADON(STT_HD) GOMCO(MAHANG) → HANGHOA(MAHANG) NHAP(STT_PN) → PHIEUNHAP(STT_PN) NHAP(MAHANG) → HANGHOA(MAHANG) PHIEUTHU(STT_HD) → HOADON(STT_HD) PHIEUNHAP(MACH) → CUAHANG(MACH) PHIEUNHAP(MAKHACH) → KHACHHANG(MAKHACH) PHIEUNHAP(MA_NV) → NHANVIEN(MA_NV) PHIEUCHI(STT_PN) → PHIEUNHAP(STT_PN) Khi thiết kế cơ sở dữ liệu chúng ta có thể ghép PHIEUNHAP, HOADON, PHIEUTHU, PHIEUCHI thành một bảng có đầy đủ các thuộc tính của chúng, cũng như vậy chúng ta có thể gép NHAP, BAN lại với nhau. Cụ thể ta có thể tổ chức cơ sở dữ liệu với các bảng cùng cấu trúc như sau: Bảng T_CH dùng để lưu trữ thông tin về cửa hàng hàng. STT Tên TT Diễn giải Kiểu độ rộng 1 F_MACH Mã số cửa hàng Text 2 2 F_TENCH Tên cửa hàng Text 50 3 F_DCCH Địa chỉ cửa hàng Text 50 Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 104
11. Giáo trình: Phân tích & thiết kế HTTT. Bảng T_KH dùng để lưu trữ thông tin về khách hàng. STT Tên TT Diễn giải Kiểu Độ rộng 1 F_MAKH Mã số khách hàng Text 6 2 F_TENKH Tên khách hàng Text 50 3 F_DCKH Địa chỉ khách hàng Text 50 4 F_MSTH Mã số thuế của khách hàng Text 15 Bảng T_HH dùng để lưu trữ thông tin về hàng hóa. STT Tên TT Diễn giải Kiểu Độ rộng 1 F_MAHH Mã số hàng hóa Text 6 2 F_TENHH Tên hàng Text 50 3 F_DVT Đơn v ị tính Text 7 Bảng T_PH dùng để lưu trữ thông tin về gốc các chứng từ: phiếu nhập kho, hoá đơn bán hàng, phiếu thu và cả phiếu chi. STT Tên TT Diễn giải Kiểu độ rộng 1 F_PSO Số phiếu Text 15 2 F_NLAP Ngày lập chứng từ Date 8 3 F_MACH Mã số cửa hàng Text 2 4 F_MAKH Mã số khách hàng Text 6 6 F_KHHD Ký hiệu hoá đơn Text 10 7 F_NPHHD Ngày phát hành hoá đơn Date 8 F_SQHD Số của quyển hoá đơn Text 5 9 F_TYLE Tỷ suất thuế GTGT Numeric 2 10 F_THUE Tiền thuế GTGT Numeric 15 11 F_ST Số tiền thu/chi Numeric 15 Bảng T_NX dùng để lưu trữ thông tin về nhập/bán hàng. STT Tên TT Diễn gi ải Kiểu Độ rộng 1 F_PSO Số phiếu Text 15 2 F_MAHH Mã số hàng hóa Text 6 3 F_SL Số lượng nhập/bán Numeric 15 4 F_DG Đơn giá nhập/bán Numeric 15 5 F_ST Số tiền nhập/bán Numeric 15 Nếu trên mỗi một phiếu thu có thể thu tiền của nhiều khách hàng hay trên một phiếu chi có thể chi trả cho nhiều khách hàng thì ta bỏ thuộc tính F_ST trong bảng T_PH mà bổ sung thêm bảng: Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 105
12. Giáo trình: Phân tích & thiết kế HTTT. Bảng T_TC dùng để lưu trữ thông tin về thu/chi. STT Tên TT Diễn gi ải Kiểu Độ rộng 1 F_PSO Số phiếu Text 15 2 F_MAKH Mã số khách hàng Text 6 5 F_ST Số tiền thu/chi Numeric 15 Lúc này ý nghĩa của thuộc tính F_MAKH ở phần gốc trên bảng T_PH là mã số của nhân viên thu tiền của khách hàng trong trường hợp phiếu thu, hay mã số của nhân viên nhận tiền để chi cho khách trong trường hợp phiếu chi. Nếu phân hoạch lưu trữ dữ liệu theo từng tháng thì ta có thể đặt tên bảng tuỳ biến theo tháng-năm. Chẳng hạn phần gốc phiếu có tên là T_PHmmyy hay T_PHyymm trong đó yy là chỉ số năm, mm là chỉ số tháng của năm yy. Đối với các phần cho T_NX hay T_TC cũng có tên là T_NXmmyy hay T_NXyymm và T_TCmmyy hay T_TCyymm tương ứng. Để làm dữ liệu chuyển sinh cho tháng sau, cần bổ sung các bảng tồn kho hàng tháng, chẳng hạn bảng T_TKmmyy có cấu trúc như sau: STT Tên TT Diễn gi ải Kiểu Độ rộng 1 F_MAKH Mã số khách hàng Text 6 2 F_MAHH Mã số hàng hoá Text 6 3 F_SLTD Số lượng tồn đầu Numeric 15,2 4 F_STTD Số tiền tồn đầu Numeric 15 5 F_SLN Số lượng nhập Numeric 15,2 6 F_STN Số tiền nhập Numeric 15 7 F_SLB Số lượng bán Numeric 15,2 8 F_STV Trị giá vốn hàng bán Numeric 15 9 F_SLTC Số lượng tồn cuối Numeric 15,2 10 F_STTC Số tiền tồn cuối Numeric 15 Hay báo cáo công nợ Phải trả cho người bán dùng bảng T_NBmmyy có cấu trúc như sau: STT Tên TT Diễn gi ải Kiểu Độ rộng 1 F_MAKH Mã số khách hàng Text 6 2 F_MAKH Mã số khách hàng Text 6 3 F_SDDKN Số dư đầu kỳ nợ Numeric 15 4 F_SDDKC Số dư đầu kỳ có Numeric 15 5 F_STN Số tiền nợ Numeric 15 6 F_STC Số tiền có Numeric 15 7 F_SDCKN Số dư cuối kỳ nợ Numeric 15 8 F_SDCKC Số dư cuối kỳ có Numeric 15 Và báo cáo công nợ Phải thu của khách hàng dùng bảng T_NMmmyy có cấu trúc hoàn toàn như trên. Một số biểu bảng không cần luân chuyển cho tháng sau như bảng kê Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 106
13. Giáo trình: Phân tích & thiết kế HTTT. hoá đơn hàng hoá dịch vụ mua vào, bảng kê hoá đơn hàng hoá dịch vụ bán ra, tình hình sử dụng hoá đơn có thể dùng các cấu trúc tương tự. Trong đó (mm) là chỉ số tháng và (yy) là chỉ số năm. Khi ghép nhiều bảng lại với nhau như vậy thì số lượng các bảng giảm, nhưng môt số cột sẽ không cần thiết đối với một số loại phiếu. Chẳng hạn F_SOHD, F_NPHHD, không cần thiết cho phiếu thu và phiếu chi. Hơn nữa cần có quy định về cách tạo giá trị môt số thuộc tính nào đó. Thuộc tính F_PSO đưa vào chung cho tất cả các loại phiếu thì phải quy ước loại phiếu nào phải tuân theo khuôn mẫu nào. Thí dụ với độ dài 15 ký tự, cách tạp ra F_SO có thể quy ước như sau: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 X X X 9 9 9 9 9 9 - m m - y y ƒ 3 ký tự đầu là loại phiếu, chẳng hạn NHH - nhập hàng hoá, BHH – hoá đơn bán hàng, TTM – thu tiền mặt, CTM – chi tiền mặt. ƒ 6 ký tự tiếp theo là số thứ tự của phiếu (theo loại phiếu) trong tháng, nếu không đầy đủ 6 chữ số thì thay bằng ký tự số 0. Các ký tự thứ 11 và 12 là chỉ số tháng, các ký tự thứ 14 và 15 là chỉ số năm. Hay cột F_MAKH (mã khách) nếu muốn phân loại khách hàng theo từng tỉnh hoặc thành phố thì có thể sử dụng 3 ký tự đầu là code điện thoại thay cho tỉnh thành còn 3 ký tự tiếp theo là số thứ tự của khách hàng theo thứ tự phát sinh theo tỉnh. Và các ràng buộc toàn vẹn: • RB1: Mỗi phiếu nhập có mua ít nhất một mặt hàng. • RB2: Mỗi hóa đơn có bán ít nhất một mặt hàng. • RB3: Tiền Thuế giá trị gia tăng của mỗi hóa đơn bằng tổng số tiền hàng nhân với tỷ lệ thuế GTGT của hóa đơn đó. Các ràng buộc toàn vẹn trên phải được kiểm tra trong suốt quá trình thao tác nếu chúng bị phi phạm. Việc tổ chức cơ sở dữ liệu cũng như tạo ra quy ước như thế nào là tuỳ thuộc vào khả năng lưu trữ nhằm đáp ứng xử lý của hệ quản trị cơ sở dữ liệu được chọn cho bài toán và người thiết kế quyết định. Nhiều công cụ hỗ trợ người thiết kế cơ sở dữ liệu như ERWIN hay POWER DESIGNER được chúng tôi đưa vào phần phụ lục mà người đọc có thể tham khảo và thực hành trước khi thực hiện. Lưu ý: Đề nghị anh/chị phát hiện những điểm chưa hợp lý (hay sai) trong thiết kế so với cơ sở dữ liệu quan hệ ở trên. Từ đó, thiết kế lại cho phù hợp. Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 107
14. Giáo trình: Phân tích & thiết kế HTTT. CHƯƠNG VIII: THIẾT KẾ THÀNH PHẦN XỬ LÝ 1. CÁC NGUYÊN TẮC 1.1. Nguyên tắc 1: xuất phát từ một DFD hợp lý Nguyên tắc cơ bản là thiết kế thành phần xử lý phải xuất phát từ lưu đồ dòng dữ liệu. Chính vì vậy mà việc có được một lưu đồ dòng dữ liệu hợp lý là điều căn bản nhất. Những xử lý chính trong toàn bộ hệ thống phải được thể hiện trong lưu đồ dòng dữ liệu. Các ô xử lý trong DFD được phân loại theo một (hoặc một số) tiêu chí nào đó và chúng phải được thể hiện trong giao diện chung của hệ thống. 1.2. Nguyên tắc 2: tính khả thi Nguyên tắc thứ hai là phải thiết kế thành phần xử lý để người dùng dễ dàng dễ thao tác, các thành phần khác tham gia xây dựng hệ thống thông tin dễ triển khai, dễ bảo trì, và dễ phát triển. 2. MỘT SỐ VẤN ĐỀ CẦN QUAN TÂM KHI THIẾT KẾ TP XỬ LÝ 2.1. Tổ chức thành phần xử lý Để tổ chức thành phần xử lý, phải tiến hành 2 quá trình ngược nhau. Quá trình thứ nhất là tiếp tục phân rã các quá trình xử lý thành các đơn thể (modul). Quá trình thứ hai là tích hợp các đơn thể xử lý theo cách thức nào đó. Quá trình 1: Phân rã các xử lý Chúng ta biết rằng việc phân rã các ô xử lý trong lưu đồ dòng dữ liệu dừng tới mức mà mỗi ô xử lý có thể nhận nhiều dòng dữ liệu vào nhưng chỉ có duy nhất một dữ liệu ra và qua đó mọi thành viên nhận thức được tất cả quá trình xử lý của hệ thống. Mỗi ô xử lý như vậy sẽ được thể hiện thành một chức năng trong giao diện chung của hệ thống. Tuy nhiên mỗi ô xử lý như vậy cũng bao gồm quá nhiều thủ tục phức tạp. Để tiếp tục làm rõ các xử lý người ta phân rã các xử lý đến mức mỗi xử lý là sự kết hợp hợp lý các đơn thể. Mỗi đơn thể như vậy cũng có thể xem là một ô xử lý nhưng ở mức độ chi tiết hơn mà có thể lắp gép với nhau để thành một ô xử lý, tuy nhiên cũng không quá chi tiết làm phức tạp vấn đề. Nghĩa là phân rã ô xử lý tới mức để có thể nhận diện các thành phần mà mỗi thành phần xử lý như vậy là đơn thể đơn nhiệm hay đơn thể đa nhiệm. Đơn thể đa nhiệm là đơn thể mà các đơn thể khác có thể gọi thực thi. Có thể gọi đơn thể đa nhiệm là một hàm mà các đơn thể khác có thể dùng mà chúng ta có thể đưa vào thư viện để dùng chung không chỉ cho các chức năng của hệ thống này mà cho cả các hệ thống khác. Thí dụ: trong hệ thống quản lý mua bán hàng, ta có thể thấy trên các chứng từ như phiếu nhập kho, hoá đơn bán hàng, phiếu thu và phiếu chi đều yêu cầu đổi số tiền thành chữ. Chúng ta có thể tạo một đơn thể có chức năng đổi một số thành chuỗi ký tự đọc số đó ra chuỗi, nghĩa là các xử lý như lập phiếu nhập kho, lập hoá đơn bán hàng, lập phiếu thu và cả lập phiếu chi, sau khi có tổng số tiền có thể yêu cầu đơn thể “đổi Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 108
15. Giáo trình: Phân tích & thiết kế HTTT. số ra chuỗi” thực thi để lấy kết quả thể hiện lên màn hình nạp dữ liệu và in lên chứng từ trên giấy nếu cần. Việc tổ chức có những đơn thể đa nhiệm như thế này sẽ tiết kiệm công sức viết phần mềm vì đối với mỗi đơn thể đa nhiệm chỉ cần thực hiện 1 lần, và nếu có sửa đổi thì chỉ cần sửa đổi trên đơn thể đó mà thôi. Đơn thể đơn nhiệm là một tập hợp các thao tác hợp lý nào đó mà chỉ thuộc trong một ô xử lý nào đó. Sự phân rã mỗi ô xử lý thành các đơn thể sẽ dễ dàng cho những người lập trình khi sử dụng một ngôn ngữ lập trình nào đó thì chỉ việc gia công để có các đơn thể sau đó “lắp gép” chúng một các hợp lý để thành một thủ tục hoàn chỉnh mà có thể thử nghiệm độc lập với các thành phần khác. Quá trình 2: Tích hợp thành phần xử lý Quá trình phân rã các ô xử lý như trình bày ở trên nhằm thấy được phần chung để dễ dàng trong việc hiểu các ô xử lý (làm như thế nào) và đặc biệt là đỡ tốn công cho người lập trình khi biết được các đơn thể đa nhiệm sẽ được dùng chung cho nhiều xử lý khác. Tích hợp các đơn thể là một quá trình ngược lại. Trước hết là tích hợp các đơn thể nào đó thành một thủ tục tương ứng với một ô xử lý trong lưu đồ dòng dữ liệu để có thể kiểm chứng tính đúng đắn của việc thiết kế. Chú ý rằng đây chưa phải là kiểm thử chức năng của phần mềm mà sự nhìn nhận, kiểm tra lại trước khi chuyển giao cho người lập trình. Sau khi gép nối các đơn thể thành các thủ tục thì có thể tích hợp chúng lại. Việc tích hợp các thủ tục có thể thực hiện bằng nhiều cách. Tích hợp tất cả các xử lý thành một hệ chung. Có thể tích hợp tất cả các chức năng của hệ thống, kể cả các chức năng hỗ trợ việc quản trị, trợ giúp vào một hệ thống. Cách thức này thích hợp với những hệ thống nhỏ, việc trì hoãn chương trình để cài đặt phiên bản phần mềm nâng vừa cấp không gây ảnh hưởng đến hoạt động của tổ chức. Phân loại thành từng nhóm Như đã nói ở phần trên, khi một hệ thống phân hoạch thành các phân hệ theo một hoặc một số tiêu chí nào đó thì việc phân nhóm các xử lý cũng kèm theo các chức năng trên. Chính vi vậy mà có thể tích hợp các thủ tục liên quan tới mỗi phân hệ đảm bảo những người dùng được phép thực thi các chức năng các phân hệ đó thao tác, vận hành. Bất luận cách nào thì sau khi gép các thủ tục với nhau cũng cần kiểm tra lại tính hệ thống của chúng. Hệ thống nên có một giao diện chung với trình điều phối thực thi các khối chức năng hoặc từng chức năng như một chương trình chính. Khi tạo thành phần mềm, cách thức phổ biến là toàn bộ hệ thống thể hiện trên giao diện chung (màn hình chính) là một biểu tượng, nếu nó được kích hoạt thì có thể thực thi một cửa sổ với nhiều chức năng hoặc một thực đơn hay một màn hình đăng nhập tùy theo cách tổ chức của người thiết kế. Chương trình chính điều phối sẽ tuỳ theo ý đồ của người thao tác mà thực hiện các bước tiếp theo. Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 109
16. Giáo trình: Phân tích & thiết kế HTTT. 2.2. Vấn đề định danh Trong một hệ thống thông tin, nhất là những hệ thống lớn, thành phần xử lý phải dùng (gọi thi hành) với nhiều loại đối tượng như thủ tục, hàm, form, report Chính vì vậy, cũng như đối với thành phần dữ liệu khi thiết kế thành phần xử lý để dễ dàng trong quản lý, việc đặt tên cho thủ tục, cho hàm tự định nghĩa, cho các biến, và cho các thành phần trên các đối tượng phải nên tuân theo những quy định chung. Việc quy ước cách thức đặt tên cho các đối tượng trong hệ thống sẽ dễ dàng cho việc viết phần mềm, bảo trì và phát triển hệ thống. Chẳng hạn tên các thủ tục có thể bắt đầu bằng 2 ký tự: p_, tên biến bắt đầu bằng 2 ký tự v_, tên các form bắt đầu bằng f_ hay tên các báo cáo bắt đầu bằng 2 ký tự r_, tên các đối tượng trên form bắt đầu bằng o_ Thí dụ: Ta có thể tổ chức thành phần xử lý cho hệ thống quản lý mua bán hàng thành các đơn thể chính như sau: đăng nhập cập nhật các biến chung thực đơn hệ thống Lập phiếu nhập kho Lập hoá đơn 1 - Cập nhật STT phiếu nhập 1 - Cập nhật STT hoá đơn 2 - gọi “cập nhật cửa hàng” 2 - gọi “cập nhật cửa hàng” 3 - gọi “cập nhật khách hàng” 3 - gọi “cập nhật khách hàng” 4 - cập nhật tỷ suất thuế GTGT 4 - cập nhật tỷ suất thuế GTGT . . * - gọi “đổi số ra chuỗi” * - gọi “đổi số ra chuỗi” cập nhật cửa hàng cập nhật khách hàng đổi số ra chuỗi Các đơn thể “lập phiếu thu” và “lập phiếu chi” cũng có thể gọi các đơn thể đa nhiệm như “cập nhật cửa hàng”, “cập nhật khách hàng” hay “đổi số ra chuỗi” ở trên. Tiếp tục phân rã tiếp thì mỗi đơn thể được trình bày bằng một lưu đồ mà ngày nay công cụ để thể hiện lưu đồ rất thuận tiện, chẳng hạn người dùng có thể sử dụng Microsoft Viso chẳng hạn. Đối với những đơn thể đơn giản thì việc trình bày bằng lưu đồ có thể bỏ qua. Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 110
17. Giáo trình: Phân tích & thiết kế HTTT. CHƯƠNG IX: THIẾT KẾ GIAO DIỆN 1. ĐẶT VẤN ĐỀ Giao diện giữa người và máy là một vấn đề cần được quan tâm trong bất cứ ứng dụng nào của tin học. Giao diện là cầu nối giữa người dùng vốn quen với các ứng xử tự nhiên và hệ thống máy tính đòi hỏi phải chính xác chặt chẽ. Dần dần giao diện được người ta quan tâm và xây dựng các chuẩn mực khi thiết kế các giao diện. Một sản phẩm phần mềm ngoài những đặc tính ưu việt bên trong, nó sẽ có ý nghĩa hơn nếu thông qua giao diện, người dùng cảm thấy thuận tiện, dễ chịu, thoải mái, thích thú khi sử dụng. Từ đó có thể nâng cao hiệu quả công việc và tránh được những vấp váp, sơ suất trong quá trình thao tác. 2. CÁC TIÊU CHUẨN THIẾT KẾ 2.1. Tính dễ sử dụng, nghĩa là có tính thân thiện với người sử dụng 9 Các chức năng dễ hiểu. 9 Phát hiện ngay lỗi của người sử dụng. 9 Dự trù sẵn một số phản ứng khi có sự cố, kết thúc không bình thường. 9 Uyển chuyển, đáp ứng nhu cầu của nhiều nhóm người sử dụng khác nhau. 9 Hoạt động theo một trật tự mà người sử dụng cảm thấy tự nhiên nhất. Nói chung là không khó học khi sử dụng. Các câu hỏi để đánh giá: 9 Biết đang ở đâu? (trong lúc khai thác). 9 Đến đây như thế nào? 9 Có thể làm gì ở đây? 9 Có thể đi tới đâu? 2.2. Tính dễ chịu sau một thời gian sử dụng 9 Màu sắc: hài hòa, nên theo các màu chuẩn. 9 Vị trí các lệnh: thống nhất giữa các màn hình. 9 Cách tiếp cận hệ thống: có cấu trúc, đơn giản, dễ hiểu. 3. CÁC CÔNG CỤ THIẾT KẾ GIAO DIỆN Bốn loại công cụ thường được sử dụng thể hiện giao diện hệ thống là: Hội thoại hỏi - trả lời: Đây là giao diện cơ bản nhất, thông thường hệ thống có những nhắc nhở yêu cầu người sử dụng thực hiện thao tác nào đó thường là nạp vào một câu lệnh hoặc tên một tập tin khả thi, thường chấm dứt việc nạp bằng phím Enter, hệ thống sẽ phân tích chỉ thị nạp vào và có những ứng xử tiếp theo. Các cửa sổ (windows): Cửa sổ là một không gian hình chử nhật trên màn hình, thường chứa nhiều biểu tượng và có thể gồm cả nhiều nhắc nhở yêu cầu người dùng thao tác. Nếu có nhiều mục cần chọn lựa người ta có thể thiết kế một cửa sổ gồm nhiều khung (Frame) mà người sử dụng có thể chọn khung này hay khung khác. Có thể kích hoạt nhiều cửa sổ nhưng tại một thời điểm chỉ có một cửa sổ hoạt động. Có thể thay đổi việc lựa chọn cửa sổ hoạt động trong số các cửa sổ đã được kích hoạt. Có thể thay đổi kích thước, thu nhỏ, phóng to, di dời vị trí và chấm dứt hoạt động của một cửa sổ Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 111
18. Giáo trình: Phân tích & thiết kế HTTT. nào đó. Đây là một công cụ phổ biến, uyển chuyển và được dùng phối hợp với những công cụ khác. Các biểu tượng (icons): Biểu tượng là những hình ảnh nhỏ, mang ý nghĩa và có thể kèm theo một chuỗi ký tự thông báo chức năng ứng với biểu tượng. Các biểu tượng có thể đặt tuỳ ý trên màn hình và được kích hoạt sử dụng nếu cần. Khi được kích hoạt, phần mềm tương ứng với biểu tượng sẽ được gọi thực thi. Chương trình đó có thể là cho kích hoạt một cửa sổ, đưa ra một thực đơn hay là tạo ra các kết quả nào đó mà có thể không được thể hiện để người dùng biết. Thông thường các biểu tượng phải có hình thức đặc trưng cho ý nghĩa của chương trình mà nó đại diện. Các thực đơn (menu): Thực đơn là hình thức giao diện phân cấp. Các chức năng được phân loại thành các nhóm chức năng. Mỗi nhóm ứng với một lựa chọn nằm ngang phía trên màn hình gọi là menu bar. Mỗi nhóm chức năng thường chứa nhiều chức năng ứng với các dòng sổ dọc xuống gọi là menu popup, mỗi chức năng nếu được chọn ứng với một chương trình nào đó. Có thể nó lại đưa ra một thực đơn thứ cấp, hoặc kết quả xử lý có thể thể hiện bằng một trong các dạng công cụ giao diện trên. Các nhóm chức năng hay các chức năng có thể được gọi bằng các phím (hoặc tổ hợp các phím) bấm tắt. Các chức năng có thể bị che mờ để không thể lựa chọn nếu không đủ điều kiện thực thi hoặc không được phép. Thực đơn là hình thức giao diện phổ biến nhất, có thể dùng cho những hệ thống có nhiều chức năng mà hầu như tất cả các sản phẩm phần mềm đều có sử dụng hình thức giao diện này. 4. CÁC GIAO DIỆN CƠ BẢN CỦA HỆ THỐNG 4.1. Giao diện chính cho hệ thống Hiện nay mỗi một phần mềm nói chung và một hệ thống thông tin nói riêng được thể hiện trên màn hình chính của máy tính bằng một biểu tượng. Tương ứng với biểu tượng này là một chương trình khả thi mà sau khi biểu tượng tương ứng với nó được kích hoạt thì chúng bắt đầu vận hành. Chương trình đó gọi là chương trình chính, nó có tác dụng thiết lập môi trường làm việc, khai báo các biến chung cho toàn bộ hệ thống. Trong số những biến này có những biến mà căn cứ vào đó để điều khiển các chức năng của hệ thống. Thông thường có một chức năng quan trọng trong chương trình chính là gọi thực thi một màn hình đăng nhập. Khi đó hệ thống lại vận hành theo điều khiển của cửa sổ đăng nhập. 4.2. Giao diện cho chức năng đăng nhập vào hệ thống Chức năng đăng nhập vào hệ thống là chức năng đầu tiên sau khi kích hoạt hệ thống hoặc chương trình chính gọi tới. Chức năng này thường phải thực hiện thông qua một màn hình giao diện đơn giản. Một số mục nhắc nhở, yêu cầu nạp thông tin về người dùng và có thể có một số nút chức năng như cho hay hoạt động, trong đó lúc đầu chức năng tiếp tục bị vô hiệu hoá. Cửa sổ giao diện là cái đầu tiên mà người sử dụng giao dịch với hệ thống. Một số nội dung chủ yếu rất thường có trong cửa sổ đăng nhập: Yêu cầu người dùng nạp những thông tin về người dùng, thường thì có 2 mục là username và password. Trong đó hình thức thể hiện nội dung password khi nạp vào bị che dấu bằng những ký tự đặc biệt nào đó để giữ tính bí mật. Có thể có thêm chức Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 112
19. Giáo trình: Phân tích & thiết kế HTTT. năng password mà chỉ được phép thực thi khi hệ thống kiểm tra biết được người dùng đó được phép thâm nhập vào hệ thống. Sau khi nạp xong hai thông tin trên hệ thống phải kiểm tra những thông tin đó và ứng xử tuỳ theo việc người dùng nạp vào những thông tin trên. Nếu căn cứ những thông tin nạp vào mà hệ thống kiểm tra thấy người đó không được phép giao dịch với hệ thống thì nên có những ứng xử tiếp theo tuỳ theo ý định của người thiết kế. Hai cách thường dùng để ứng xử với trường hợp này là hoặc từ chối việc đăng nhập vào hệ thống, trở về giao diện chung hoặc có thể vô hiệu hoá nút chức năng tiếp tục yêu cầu nạp lại các mục trên để ứng xử tiếp theo. Nếu người dùng được phép khai thác hệ thống thì dựa theo sự phân quyền của người quản trị hệ thống mà hệ thống sẽ gán trị cho các biến điều khiển các chức năng của hệ thống ứng với người dùng này. Chẳng hạn nếu việc điều khiển các chức năng của hệ thống bằng một cửa sổ chứa các biểu tượng thì những chức năng mà người dùng không được phép thưc thi có thể không cho xuất hiện hoặc dấu đi hay vô hiệu hoá chúng, chỉ những biểu tượng mà người dùng đó được phép thực thi mới hiển thị để người dùng lựa chọn. Nếu việc điều khiển các chức năng của hệ thống bằng thực đơn thì những chức năng không được phép bị làm mờ đi nghĩa là vô hiểu hoá việc gọi nó để thực thi. Nếu người dùng sau khi nạp các thông tin trên và được phép khai thác hệ thống thì có thể chọn chức năng đổi mật khẩu. Khi đó một cửa sổ phục vụ việc đổi mật khẩu của người dùng được kích hoạt. Dĩ nhiên người dùng chỉ được phép đổi mật khẩu của bản thân mà tôi. Để phục vụ việc quản trị người dùng, người ta lưu những dữ liệu cần thiết của người dùng vào một bảng (ta tạm gọi là bảng Users) mà quyền khai thác chỉ có người quản trị hệ thống mà thôi. Bảng này ít ra có các thuộc tính chứa thông tin về người dùng (như username, password), tính được phép thao tác hệ thống hay không thông qua một thuộc tính nào đó (thuộc tính permission chẳng hạn), và các cột kiểu logic mà giá trị của nó sẽ được gán cho các biến điều khiển các chức năng hệ thống. Số những thuộc tính này nhiều hay ít tuỳ theo số chức năng của hệ thống và phạm vi quản trị mà người ta muốn phân quyền. Khi thiết kế cửa sổ hoặc thực đơn giao diện cho hệ thống, những biến này được dùng để quyết định chức năng tương ứng trong giao diện có được thực thi hay không. Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 113
20. Giáo trình: Phân tích & thiết kế HTTT. Thí dụ: sau khi kích hoạt biểu tượng ứng với hệ thống kế toán, cửa sổ đăng nhập có hình thức như sau: Khi người dùng nạp các thông tin cần thiết về username và password, hệ thống sẽ kiểm tra dữ liệu của người dùng trong bảng users đã được mở. Nếu hệ thống kiểm tra thấy người dùng được phép thì nút chức năng continue có hiệu lực và nếu người dùng chọn nút continue để tiếp tục thì hệ thống gọi thực thi một chức năng khác, thí dụ một cửa sổ cho cập nhật giá trị một số biến chung mà giá trị của nó không thay đổi trong suốt quá trình vận hành các chức năng của hệ thống trừ khi chọn chức năng thay đổi giá trị các biến này, sau đó mới gọi giao diện chung của hệ thống. Chẳng hạn các hệ thống liên quan tới học tập như hệ thống quản lý học sinh, quản lý công tác giảng dạy, quản lý công tác thực tập tốt nghiệp hay thực hành tin học thì nên có giao diện cho phép cập nhật học kỳ và niên khoá mà người dùng muốn thao tác. Mọi xử lý về sau đều chỉ trong phạm vi của học kỳ và niên khoá đã chọn. Hay trong hệ thống kế toán hoặc quản lý mua bán hàng mà người ta phân hoạch dữ liệu và các chức năng xử lý theo từng tháng thì chúng ta có thể tổ chức một cửa sổ cập nhật giá trị biến tháng (và năm) này. Mọi xử lý về sau như lập báo cáo tồn kho, thẻ kho, tình hình kinh doanh bán hàng, lập bảng kê hoá đơn hàng hoá dịch vụ mua vào, lập bảng kê hoá đơn hàng hoá dịch vụ bán ra là của tháng năm đó. Tầm vực của biến là một vấn đề quan trọng trong lập trình mà chúng ta không đề cập ở đây. Thí dụ giao diện cho cập nhật giá trị học kỳ - niên khoá hay ngày tháng trong những hệ thống trên. Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 114
21. Giáo trình: Phân tích & thiết kế HTTT. Menu là hình thức giao diện phổ biến để điều khiện hệ thống. Thí dụ với giao diện cho hệ thống kế toán dưới đây, người dùng được phép đến một chức năng nào đó trong các chức năng được phép để thực hiện, những chức năng khác không được phép bị “làm mờ” đi để người dùng không được phép thực hiện. 5. CÁC CHỨC NĂNG PHÂN QUYỀN Chức năng phân quyền thường chỉ có người quản trị hệ thống mới được phép thực thi. Nó được dùng để người quản trị phân quyền cho những người dùng (hoặc nhóm người dùng). Một trong những cách thức quản trị người dùng là tạo một bảng (chẳng hạn có tên là users) chứa các thông tin về người dùng như tên (username), họ tên, mật khẩu (password), được phép thao tác với hệ thống hay không (chẳng hạn thuộc tính permissison) và tất cả các thuộc tính mà mỗi thuộc tính đều có cấu trúc kiểu logic ứng với chức năng mà người dùng đó được phép (mang giá tri true) hay không (mang giá trị false), có thể thêm các thuộc tính để đặc tả phạm vi của người dùng. Giao diện để người quản trị phân quyền cho người dùng phải cập nhật tất cả những thuộc tính trên của người dùng. Vì số lượng các chức năng có thể quá nhiều so với không gian của một cửa sổ nên có thể dùng nhiều trang để hiển thị. Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 115
22. Giáo trình: Phân tích & thiết kế HTTT. Thí dụ một phần của bảng quản trị người dùng như dưới đây: Để dễ dàng cho việc phân quyền người ta thiết kế một giao diện phân quyền để người quản trị hệ thống (và chỉ có người đó) sử dụng để phân quyền cho các người dùng. Thực chất giao diện đó làm chức năng cập nhật các thuộc tính của một bộ ứng với người dùng trong bảng trên. Thí dụ: giao diện cửa sổ phân quyền cho người dùng của hệ thống kế toán: Khi lựa chọn cập nhận thì các giá trị này được cập nhật vào bảng users của người dùng trên. Sau này khi người dùng đăng nhập vào hê thống thông qua màn hình đăng nhập mà đã được đề cập ở trên, những giá trị này được gán cho các biến có chức năng điều khiển các chức năng của giao diện hệ thống. Muốn làm được điều này thì khi thiết kế giao diện hệ thống phải sử dụng các biến điều khiển này. Chẳng hạn nếu dùng hình thức thức đơn để làm giao diện của hệ thống thì khi thiết kế ta dùng các biến trên để điều khiển giao diện của hệ thống. Thí dụ trong Visual Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 116
23. Giáo trình: Phân tích & thiết kế HTTT. Foxpro khi thiết kế giao diện cho hệ thống ta khai báo tền biến sau mục skip for như sau: Dùng biến để điều khiển giao diện của hệ thống Thì khi thực thi thực đơn, nếu giá trị của biến lp_ttm là false thì chức năng “Lập phiếu thu tiền mặt” sẽ bị mờ đi, nghĩa là người đó không được phép lập phiếu thu tiền mặt. Nếu sử dụng Visual Basic hay các công cụ khác để thiết kế thực đơn thì cách thức thực hiện cũng tương tự như vậy. Quản trị người dùng là những yêu cầu thiết yếu với bất kỳ hệ thống thông tin nào. Để thực hiện tốt chức năng này đòi hỏi người phân tích phải liệt kê hết tất cả các chức năng của hệ thống cần phân quyền, nắm cụ thể những người dùng hay nhóm người dùng nào, phạm vi của mỗi người hay nhóm người đó ra sao, và người thiết kế biết tổ chức dữ liệu (thiết kế bảng users) và giao diện phân quyền cho hợp lý. Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 117
24. Giáo trình: Phân tích & thiết kế HTTT. 6. THIẾT KẾ MÀN HÌNH CẬP NHẬT DỮ LIỆU Mục tiêu của thiết kế đầu vào là đưa dữ liệu vào hệ thống. Việc đưa dữ liệu vào hệ thống thường được thông qua một màn hình giao diện mà thường gồm nhiều mục nạp nhập và các nút chức năng (hay một tổ hợp các phím điều khiển). Hiện tại có nhiều công cụ trực quan thuận tiện cho phép người lập trình trong việc thể hiện các thiết kế cho màn hình nạp dữ liệu. Dữ liệu đưa vào phải chính xác như nó được phát sinh trong thế giới thực và phải được kiểm tra tất cả các ràng buộc để bảo đảm tính nhất quán. Việc đưa dữ liệu vào phải bảo đảm những yêu cầu của người dùng như dễ sử dụng, có thể thao tác nhanh, và có những trợ giúp khi nạp nhập nếu gặp các tình huống. Ngoài ra việc nạp nhập phải bảo đảm các yêu cầu kỹ thuật như xử lý nhanh, kiểm tra chính xác và giải quyết được những đụng độ, tranh chấp khi nhiều người cùng thao tác đến một cơ sở dữ liệu. Những đòi hỏi trên đòi hỏi phải có một bản đặc tả chi tiết trước khi chuyển cho bộ phận lập trình. Khi thiết kế một giao diện nạp dữ liệu phải vạch rõ những điểm sau: • Mục đích của màn hình nạp dữ liệu - thể hiện ô xử lý nào trong DFD. • Môi trường dữ liệu cho việc nạp nhập, cụ thể là nêu rõ việc nạp nhập phải đưa dữ liệu vào những bảng nào, những thuộc tính nào, phải tham khảo những bảng nào, dùng những bảng tạm thời để tạo thuận lợi cho việc nạp nhập nếu cần cũng phải được nêu ra ở đây. • Hình thức của màn hình nạp dữ liệu như thế nào. Các thông báo: tiêu đề, các thông báo nhắc nhở, các mục nạp nhập, các nút chức năng. Các thông báo nhắc nhở phải đơn giản, ngắn gọn, dễ hiểu, tránh nhầm lẫn. Hình thức của màn hình phải được thiết kế tương tự như chứng từ gốc, nếu có thể thì giữ nguyên hình dạng để người dùng thao tác thuận tiện. Trong hệ thống có thể có nhiều chức năng đưa hoặc cập nhật dữ liệu trong hệ thống thì các màn hình nạp nhập phải có hình thức tương tự nhau. Chẳng hạn vị trí các nút chức năng trên các màn hình đó phải giống nhau. • Cách thức vận hành của màn hình nạp dữ liệu khi thao tác: cụ thể lúc bắt đầu khởi tạo những xử lý nào được thi hành, thứ tự các mục nạp nhập ra sao, đặc biệt là phải đặc tả tất cả các ứng xử đối với từng mục nạp nhập hay thao tác. Những ý tưởng của ứng xử này phải thể hiện được việc thoã mãn các yêu cầu của người dùng và công cụ trợ giúp cũng có khả năng triển khai được. • Đối thoại giữa người sử dụng và hệ thống trong từng mục nạp nhập phải có tính hợp lý cho người lập trình khi thảo chương và người thao tác khi triển khai sử dụng ở các giai đoạn sau. Chẳng hạn để đơn giản những mục nạp nhập có thể tham khảo, chọn trong dữ liệu đã có nếu đối tượng cần chọn đã tồn tại trong cơ sở dữ liệu. Một trong những hình thức thường được dùng trong các công cụ hiện nay là trình ra một danh sách thường gồm nhiều thuộc tính của các đối tượng để lựa chọn. Tuy nhiên hình thức đó thuận tiện khi số dữ liệu để lựa chọn hạn chế, nếu không gian tìm kiếm đối tượng lớn thì phải thiết kế những chức năng hỗ trợ thêm để trợ giúp người thao tác thuận tiện. Cần chú ý đến tình huống là nếu đối tượng đưa vào nạp nhập chưa có trong cơ sở dữ liệu thì ứng xử tiếp theo là thế nào? người thao tác có được phép nạp thông tin của đối Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 118
25. Giáo trình: Phân tích & thiết kế HTTT. tượng đó vào cơ sở dữ liệu hay không? nếu được phép thì có khởi tạo một màn hình khác cho việc bổ sung dữ liệu đó hay không Những tình huống xảy ra trong thế giới thực phải được đề cập trong ý tưởng thiết kế. Bảng ửng xử này là một kịch bản ửng xử, tương tác giữa người thao tác và hệ thống. Có nhắc nhở, hướng dẫn khi cần. Việc xử lý nên tránh những công đoạn thừa, các xử lý mâu thuẫn nhau, chẳng hạn nếu kiểm tra 2 ràng buộc: số tiền=số lượng*đơn giá và đơn giá=số tiền/số lượng có thể xảy ra những sai số. • Vấn đề kiểm tra các ràng buộc toàn vẹn cần phải quyết định thời điểm kiểm tra, tốt nhất là tức thì sau khi nạp nhập mục mà có thể vi phạm ràng buộc. • Màn hình nạp dữ liệu thường được vận hành để nạp nhiều phiên kế tiếp nhau, chẳng hạn việc lập hoá đơn bán hàng được thực hiện hết hoá đơn này đến hoá đơn khác nên mặc nhiên sau khi hoàn thành cập nhật xong một hóa đơn thì nên lại bắt đầu cập nhật một hoá đơn khác. Hồ sơ thiết kế là tài liệu kỷ thuật quan trọng, cần được viết đầy đủ, chính xác và phải kiểm tra cẩn thận trước khi chuyển giao cho người lập trình. Thí dụ sau đây là hồ sơ thiết kế của màn hình “lập hoá đơn bán hàng” trong “hệ thống quản lý mua bán hàng”. • Mục đích: đưa thông tin từng hoá đơn bán hàng vào cơ sở dữ liệu của hệ thống quản lý mua bán hàng. • Môi trường dữ liệu • Lập một hoá đơn có chức năng thêm một bộ vào bảng T_PH và đưa một số bộ bằng số mặt hàng trên hoá đơn vào bảng T_NX. Điều này có được do xét mối liên quan giữa ô xử lý “lập hoá đơn” trong DFD và các thực thể, các mối kết hợp trong ERD. Các bộ của bảng T_NX và 1 bộ trên bảng T_PH của một hóa đơn sẽ có cùng giá trị của thuộc tính F_PSO trên cả hai bảng đó. T_PH F_PSO F_NLAP F_MACH F_MAKH F_TYLE F_THUE BHH01 BHH02 BHH03 BHH04 BHH19 11-09-06 03 071056 10% T_NX F_PSO F_MAHH F_SL F_DG F_ST BHH19 A 10 200 2000 BHH19 B 20 300 6000 BHH19 C 10 100 1000 BHH19 D 30 500 15000 BHH19 E 60 150 9000 BHH19 F 70 400 28000 BHH19 G 10 300 3000 Khi lập hoá đơn bán hàng phải tham khảo tới những bảng T_CH, T_KH và T_HH để tìm kiếm các đối tượng như cửa hàng, khách hàng, mặt hàng tương ứng trên các bảng Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 119
26. Giáo trình: Phân tích & thiết kế HTTT. đó. Nếu đối tượng mới thì phải có thao tác bổ sung dữ liệu về đối tượng đó vào các bảng tương ứng trên trước khi gán mã số vào hai bảng T_PH, T_NX hay T_HH đã nêu ở trên. Khi lập một hoá đơn bán hàng là đưa thêm dữ liệu vào hai bảng T_PH và T_NX nói trên, tuy nhiên không nên can thiệp trực tiếp vào các thành phần của chúng vì nếu trong quá trình thao tác có khi cần phải quay lại những giá trị cũ thì sẽ gặp khó khăn. Do đó có thể sử dụng các bảng tạm thời có cấu trúc “tương tự” như hai bảng trên để đề phòng đường phục hồi lại những giá trị cũ nếu người dùng không muốn thay đổi. Chẳng hạn chúng ta dùng một bảng có tên là T_TEMP1 có cấu trúc giống hoàn toàn cấu trúc của bảng T_PH như chỉ có 1 bộ (chỉ dùng cho 1 hoá đơn) và một bảng T_TEMP2 gồm 10 bộ (cho tối đa 10 mặt hàng trên 1 hoá đơn) với cấu trúc như sau: Bảng T_TEMP2 dùng để lưu trữ tạm thời thông tin về 1 hoá đơn bán hàng. STT Tên TT Diễn gi ải Kiểu Độ rộng 1 F_MAHH Mã số hàng hóa Text 6 2 F_TENHH Tên hàng hoá Text 50 3 F_DVT Đơn vị tính Text 7 4 F_SL Số lượng bán Numeric 15 5 F_DG Đơn giá bán Numeric 15 6 F_ST Số tiền bán Numeric 15 Chú ý là không có thuộc tính T_PSO. Cụ thể: T_TEMP1 F_PSO F_NLAP F_MACH F_MAKH F_TYLE BHH20 11-09-06 04 071057 10% 1 2 3 4 5 6 7 8 9 10 11 T_EMP2 F_MAHH F_TENHH F_DVT F_SL F_DG F_ST I 10 200 2000 J 20 300 6000 K 10 100 1000 L 30 500 15000 M 60 150 9000 N 70 400 28000 Tất cả những bảng trên phải được tạo (nếu chưa tồn tại) và mở khi bắt đầu thao tác lập hoá đơn. Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 120
27. Giáo trình: Phân tích & thiết kế HTTT. Hình thức của màn hình “lập hoá đơn”. 1 HOÁ ĐƠN BÁN HÀNG 1 Số phiếu: 1 1 2 3 1 4 Quyển số: Loại hoá đơn: Ký hiệu hoá đơn: 51 61 Ngày PHHĐ: Ngày lập: 1 71 8 91 Mã số cửa hàng: 1 1 101 11 12 Mã số khách hàng: Mã hàng Tên hàng ĐVT Số lượng Đơn giá Thành tiền 1 1 14 1 1 1 1 13 15 16 17 18 1 19 Cộng tiền hàng: 1 1 21 20 221 Tỷ suất thuế GTGT: Tiền thuế GTGT: 1 23 Số tiền viết bằng chữ: 1 1 1 1 24 25 26 27 Lưu và in Xóa Làm lại Đóng Trong hình thức hoá đơn bán hàng trình bày ở trên có sự tương ứng giữa mỗi ô với các thuộc tính trong hai bảng T_TEMP1 và T_TEMP2 như sau: STT ô Cột STT ô Cột 1 F_PSO 13 F_MAHH 2 F_SQHD 14 F_TENHH 3 F_LOAIHD 15 F_DVT 4 F_KHHD 16 F_SL 5 F_NLAP 17 F_DG 6 F_NPHHD 18 F_ST 7 F_MACH 10 F_MAKH 20 F_TYLE 21 F_THUE ƒ Ô số 8 và số 9 là giải mã tên và địa chỉ cửa hàng ứng với mã cửa hàng ở ô thứ 7. Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 121
28. Giáo trình: Phân tích & thiết kế HTTT. ƒ Ô số 11 và số 12 là giải mã tên và địa chỉ của khách hàng ứng với mã khách hàng ở ô thứ 10. Ô 19 là tổng cột số tiền của các ô 18. Ô 21 có được bằng ô 19 nhân với ô 20 rồi chia cho 100. Ô bằng ố 19 cộng với ô 21. Ô 23 có được bằng cách đổ số tiền trong ô 23 ra chuỗi. Các ô 24, 25, 26 và 27 là các nút chức năng có tên tương ứng đặc tả ở trên. Đặc tả từng thành phần trên màn hình “lập hoá đơn”: Việc đặc tả từng thành phần trên một màn hình nạp dữ liệu phải thể hiện được tất cả yêu cầu của các nguyên tắc thiết kế giao diện. Đây là kịch bản giao tác giữa người sử dụng và hệ thống. Người dùng phải thao tác như thế nào, hệ thống phải cung cấp cái gì, xử lý như thế nào ứng với từng cách thao tác của người sử dụng. Việc đặc tả phải thể hiện ý tưởng của người thiết kế và thảo chương viên có thể dùng công cụ đã chọn để triển khai ý tưởng khi lập trình. Thành phần thứ 1: sau thông báo “Phiếu số:” là thành phần số phiếu. Trong thực tế việc lập hoá đơn được thực hiện liên tiếp hết hoá đơn này đến hoá đơn khác. Số thứ tự hoá đơn trên cùng một quyển hoá đơn tăng liên tục và đã được in sẵn, nhưng khi thay đổi các quyển hoá đơn thì thứ tự này không còn mang tính liên tục được nữa, tuy các quyển hoá đơn khác nhau thì mang số quyển khác nhau. Vì vậy để dễ dàng trong việc quản lý ta bổ sung thêm thuộc tính F_PSO - tức là số phiếu, độc lập với số hoá đơn để dễ dàng điều khiển. Như vậy một lẽ tự nhiên là khi lập một hoá đơn mới giá trị của nó phải “tăng lên 1 đơn vị”. Để người dùng đơn giản trong việc thao tác, giá trị này nên được tự động tạo ra để bớt thao tác trừ trường hợp người dùng muốn thay đổi giá trị để tìm và điểu chỉnh (nếu được phép) một hoá đơn đã có. Ý tưởng là vậy nhưng để thực hiện được điều này thì phải biết tổ chức dữ liệu và thực hiện nhiều thao tác sơ cấp. Chẳng hạn để làm được điều đó ta phải sắp xếp dữ liệu trong bảng T_PH bởi thuộc tính F_PSO. Đến hoá đơn cuối cùng để biết giá trị F_PSO của nó là bao nhiêu, sau đó chỉ cần “tăng lên 1” làm giá trị của F_PSO cho hoá đơn mới. Trong trường hợp trong bảng T_PH chưa tồn tại hoá đơn nào thì hoá đơn mới sẽ “bắt đầu từ 1”. Chú ý là cấu trúc của giá trị thuộc tính F_PSO đã được mô tả trong phần trước nên cách tạo ra nó cũng chẳng khó khăn gì. Nhưng nếu đặt trong trường hợp khi tổ chức dữ liệu tập trung trên SEVER mà có thể nhiều người cùng lập hoá đơn. Mỗi hoá đơn chỉ có một F_PSO cho nên không thể để xảy ra trường hợp có hơn một người cùng lập một hoá đơn. Để giải quyết đụng độ này ta có thực hiện bằng cách khi một người lập một hoá đơn mới thì cố gắng có được đặc quyền chiếm dụng bảng T_PH. Khi người này có đặc quyền chiếm dụng thì người khác không thể thêm bớt hay thay đổi bất cứ một mục gì trên bảng này được. Khi tạo được giá trị của thành phần (1) cho hoá đơn mới thì bổ sung ngay một bộ mới mà F_PSO là giá trị của (1) như đã xác định như trên. Giá trị này cũng được gán cho F_PSO trong bảng T_TEMP1. Thao tác này hoàn thành thì có thể tạm thôi chiếm cứ độc quyền trên bảng T_PH để dành cho những người khác. Chú ý sau đó nên không cho phép thay đổi giá trị của thành phần này nữa vì mọi thao tác với các thành phần còn lại liên quan tới hoá đơn có F_PSO mang giá trị đã tạo ra ở trên. Nếu được phép thay đổi giá trị này tức là ta thực hiện với một hoá đơn khác. Trong trường hợp người dùng nạp giá trị của thành phần 1 có giá trị bằng F_PSO của một hoá đơn đã có thì ứng xử có thể là phải đưa tất cả thông tin lên màn hình tương ứng với từng vị trí để người dùng xem xét và điều chỉnh nếu được phép. Việc đưa tất Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 122
29. Giáo trình: Phân tích & thiết kế HTTT. cả thông tin của hoá đơn đã có lên màn hình thực chất là tạo một bản sao mà phần gốc hoá đơn trong bảng T_PH được đưa ra bảng T_TEMP1 và phần chi tiết của cùng hoá đơn trong bảng T_NX được đưa ra bảng T_TEMP2 tương ứng. Những thuộc tính như F_TENHH, F_DVT không có trong T_NX nhưng có thể tạo giá trị được bằng việc giải mã cột F_MAHH nhờ tham khảo bảng T_HH. Thành phần thứ 2: sau thông báo “Quyển số:” là thành phần số của quyển hoá đơn. Giá trị này cũng như Loại hoá đơn (thành phần thứ 3) và Ký hiệu hoá đơn (thành phần thứ 4) là chung cho tất cả các hoá đơn trên quyển đó. Những quyển hoá đơn này công ty phải mua từ cục thuế, nghĩa là chúng đã được in sẵn và được quản lý rất chặt chẽ. Những hoá đơn hỏng hóc phải được giải trình, làm mất sẽ chịu phạt và thậm chí bị truy tố nếu gây ra hậu quả nghiêm trọng. Thông thường một quyển có 50 hoá đơn, mỗi hoá đơn có 3 liên với 3 màu khác nhau. Khi viết hoá đơn bẳng tay người ta chỉ viết trên một tờ sau khi đặt các tờ giấy than để cùng một nội dung được ghi lên hai liên còn lại. Liên màu đỏ sẽ được giao cho khách. Nếu sau này việc lập hoá đơn được xử lý và in ra bằng máy thì tốt nhất cũng nên chọn cách làm tương tự như vậy với máy in kim. Như vậy số của quyển hoá đơn (cũng như Loại hóa đơn và Ký hiệu hoá đơn) sẽ không thay đổi khi các hoá đơn được lập trong cùng một quyển, giá trị này nên kế thừa (giữ giá trị cũ) trừ khi chuyển sang lập hoá đơn cho quyển khác. Giá trị của thành phần 2 tương ứng với giá trị của thuộc tính F_QSHD trong bảng T_TEMP1. Thành phần thứ 3 và thành phần thứ 4: tương tự như thành phần 2. Giá trị của các thành phần này ứng với giá trị của thuộc tính F_LOAIHD và F_KHHD trong bảng T_TEMP1 tương ứng. Thành phần thứ 5: sau thông báo “Ngày lập:” là thành phần ngày lập phiếu. Nên chọn giá trị mặc nhiên là ngày hiện tại, và giá trị này cũng nên kế thừa khi lập hoá đơn tiếp theo. Thành phần thứ 6: sau thông báo “Ngày PHHĐ:” là thành phần ngày phát hành hoá đơn. Đối với hoá đơn bán hàng thì thông thường ngày phát hành hoá đơn và ngày lập phiếu là như nhau, trong trường hợp là phiếu nhập kho thì có thể khác nhau. Tuy vậy cũng nên chọn giá trị mặc nhiên là ngày hiện tại, và giá trị này cũng nên kế thừa khi lập hoá đơn tiếp theo để tiết kiệm thao tác trong khi lập hoá đơn. Những dữ liệu kiểu Date này thường được hệ quản trị cơ sở dữ liệu kiểm tra tính hợp lý giá trị của nó nếu người dùng lỡ nạp sai (thí dụ ngày 30-02-2006 chẳng hạn!). Thành phần thứ 7: sau thông báo “Mã số cửa hàng:” là thành phần Mã số cửa hàng nơi xuất hàng cho hoá đơn được lập. Số các cửa hàng cũng không nhiều nên có thể có nhiều cách thiết kế cho ô xử lý này. Một trong những cách đơn giản là cho người dùng nạp vào giá trị của mã số cửa hàng rồi kiểm tra tính hợp lý của nó. Nếu giá trị đó bằng mã số của một cửa hàng đã tồn tại trong cơ sở dữ liệu thì giải mã tên và địa chỉ cửa hàng ở hai thành phần thứ 8 và 8 kế bên. Người dùng xem xét nếu thấy đúng là cửa hàng nơi phát sinh ra hoá đơn đã được chọn thì chuyển sang mục kế tiếp là Mã số khách hàng. Nếu thấy chưa hợp lý thì người dùng có khả năng quay trở lại nạp vào một giá trị khác để thử. Vì số cửa hàng không nhiều, người thao tác cũng đã được quen nên những xử lý kiểm tra cho tính hợp lý thành phần này mang tính thủ tục. Tuy nhiên những sai sót không cố ý chẳng hạn gõ nhầm hoặc sai mã số cửa hàng thì phải thông báo, nhắc nhở và có những ứng xử Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 123
30. Giáo trình: Phân tích & thiết kế HTTT. hợp lý như nhắc nhở, hướng dẫn thao tác xử lý sự cố đó. Nếu hệ thống đã phân quyền cho người đang dùng chỉ được lập hoá đơn cho những cửa hàng nào trong số các cửa hàng của công ty thì cũng phải thiết lập bộ lọc để để thể hiện phạm vi của quyền hạn đó. Nếu việc đánh số thứ tự của số phiếu cũng phải theo từng cửa hàng thì thao tác chọn cửa hàng sẽ được chọn trước khi gọi màn hình lập hoá đơn. Một cách thường được sử dụng là đưa ra một danh sách thông tin cần thiết như mã số, tên, địa chỉ các cửa hàng mà người đang thao tác có quyền lập hoá đơn để chọn. Người thao tác chỉ cần chọn một cửa hàng xong hệ thống gán mã số, tên và địa chỉ của cửa hàng đó vào các thành phần thứ 7, 8, 9 tương ứng. Ngày nay có nhiều công cụ hổ trợ để thể hiện ý tưởng trên mà người lập trình dễ dàng nắm bắt cách thức này. Thành phần thứ 10: sau thông báo “Mã số khách hàng:” là thành phần Mã số khách hàng - người hoặc đơn vị mà công ty sẽ bán hàng cho ứng với hoá đơn được lập. Cách ứng xử đối với thành phần mã số cửa hàng như đối với thành phần thứ 7 như trình ày ở trên cũng có thể được sử dụng nơi đây. Tuy nhiên số lượng khách hàng mà công ty đã giao dịch có thể rất nhiều, việc nạp vào rồi kiểm tra theo kiểu thử đúng – sai như trên sẽ rất khó khăn vì người thao tác khó có thể nhớ để thao tác cho chính xác. Hay hình thức đưa ra một danh sách thông tin các thuộc tính như mã khách, tên khách, địa chỉ khách hàng để người dùng lựa chọn cũng bị hạn chế do không gian thể hiện danh sách cũng bị hạn chế (tối đa được khoảng vài ba chục khách hàng). Hơn nữa nếu như khi bán cho một khách hoàn toàn mới thì việc bổ sung thông tin khách hàng này vào danh mục khách hàng phải gọi một xử lý khác. Một cách đơn giản mà khả thi cho mục này có thể thực hiện như sau mà vẫn thể hiện tính thuận tiện cho người sử dụng. Hệ thống cho phép người dùng nạp vào giá trị nào đó của thành phần thứ 8. Việc nạp vào các vị trí trong thành phần này đúng theo quy ước của việc tạo mã số khách hàng mà chúng ta đã trình bày ở phần thiết kế cơ sở dữ liệu. Thí dụ cách phân loại khách hàng theo tỉnh / thành phố sẽ đơn giản phạm vi tìm kiếm và đối với những người thao tác thường xuyên sẽ định vị tương đối chính xác mã số khách hàng. Nếu như người dùng nạp vào một mã số gần chính xác thì có thể quay lại nạp thử để kiểm chứng. Đây là một ứng xử tự nhiên và rất hợp lý khi hệ thống đưa vào triển khai thực tế. Ta có thể đưa ra một ý tưởng thiết kế như sau: trong trường hợp người dùng nạp vào một ký tự đặc biệt mà ký tự này không thể là một ví trí trong mã số của bất cứ khách hàng nào, chẳng hạn dấu hỏi chấm “?”. Hệ thống phải đưa ra danh sách các thuộc tính cần thiết như mã số, tên, địa chỉ, mã số thuế của khách hàng để người dùng lựa chọn. Việc đưa ra danh sách như vậy có thể quy định là không được phép sửa và xoá nhưng có thể được phép bổ sung trong trường hợp phát sinh một khách hàng mới. Đặc biệt có thể dùng chức năng tìm kiếm phổ dụng mà hầu như tất cả các công cụ thường dùng (chẳng hạn trong các phần mềm của Microsoft là tổ hợp phím Ctrl+F) dựa vào bất cứ thông tin nào như một phần của tên, địa chỉ hay mã số thuế của khách. Lúc này người dùng không cần duyệt xem - chọn như hình thức đã nêu trong thành phần thứ 7 mà hệ thống tự tìm kiếm, định vị đến khách hàng muốn tìm để người dùng kiểm tra và lựa chọn nếu thấy hợp lý. Chúng ta cũng không cần quan tâm tới phạm vi tìm kiếm là nhỏ Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 124
31. Giáo trình: Phân tích & thiết kế HTTT. hay lớn vì tốc độ tìm kiếm do hệ thống thực trên cơ sở dữ liệu đang dùng không đáng quan tâm về mặt thời gian. Nếu hệ thống không hỗ trợ những chức năng tìm kiếm và bổ sung khách hàng như vậy thì chúng ta có thể tạo những chức năng tìm kiếm bổ sung khách với những yêu cầu ứng xử như mô tả ở trên vào màn hình lập hoá đơn để hỗ trợ người dùng. cách thức này cũng có thể áp dụng cho thành phần thứ 7 (Mã số cửa hàng) đã nêu trên và thành phần thứ 13 “Mã hàng” trong phần chi tiết hoá đơn. Bằng một trong những phương pháp trên, sau khi lựa chọn thông qua những thông tin về khách hàng từ việc tham khảo bảng T_KH, phải gán mã số hàng hoá cho thành phần thứ 10 và giải mã tên và địa chỉ khách hàng ở hai thành phần kế tiếp. Dữ liệu tương ứng với thành phần thứ 10 này là giá trị của thuộc tính F_MAKH trong bảng T_TEMP1. Thành phần thứ 13: dưới thông báo “Mã hàng” là Mã số hàng hoá. Mỗi một hoá đơn có thể bán cho khách hàng nhiều mặt hàng, việc thiết kế những ứng xử cho thành phần này cũng tương tự như đối với thành phần thứ 10 ở trên. Thành phần thứ 14, và 15 là giải mã tên hàng và đơn vị tính cho mã hàng đã chọn hay nạp vào. Dữ liệu tương ứng cho các thành phần này là giá trị của các thuộc tính F_MAHH, F_TENHH và F_DVT trong bảng T_TEMP2 tương ứng. Thành phần thứ 16 và 17: dưới thông báo “Số lượng” và “Đơn giá “ là số lượng và đơn giá của mặt hàng có mã số đã chọn ở thành phần thứ 13 được giải mã bằng tên và đơn vị tính bên cạnh. Hai giá trị này yêu cầu người dùng nạp vào. Mỗi lần thay đổi giá trị số lượng hay đơn giá thì nên tính lại thành phần thứ 18 tức Số tiền theo công thức Số tiền = Số lượng x Đơn giá. Cột số tiền được suy ra từ 2 cột Số lượng và đơn giá nên không cần phải nạp nhập. Cũng có thể sau mỗi lần nạp hoặc thay đổi giá trị của hai thành phần trên ở bất kỳ hàng nào thì ngoài việc tính lại thành phần thứ 18 tương ứng với hàng đó mà tính luôn cả thành phần thứ 19, 21, 22 và thực thi chức năng đổi giá trị của thành phần thứ 22 thành chuỗi số tiền viết bằng chữ gán trị cho thành phần thứ 23. Giá trị của các thành phần 16, 17, 18 ứng với giá trị của các thuộc tính F_SL, F_DG và F_ST tương ứng trong bảng T_TEMP2. Chú ý là các thành phần từ 13 đến 18 là có thể lặp đi lặp lại trong một lưới gồm nhiếu dòng. Số dòng thể hiện trên giao diện có thể ít hơn số mặt hàng được bán trong hoá đơn, tuy nhiên lưới này có thể cuộn lên hay cuộn xuống để người dùng tham khảo và thao tác. Quá trình cập nhật các thành phần 13, 16, 17 kết thúc khi số mặt hàng trên hoá đơn được cập nhật xong. Trên thực tế thì số mặt hàng thể hiện trên một hoá đơn tối đa là 10, tuy nhiên nếu không bắt buộc điều này thì có thể tăng thêm để giảm bớt số lượng hoá đơn phát hành. Thành phần thứ 20: sau thông báo “Tỷ suất thuế GTGT:” là tỷ suất thuế giá trị gia tăng của hoá đơn. Chú ý rằng trên một hoá đơn chỉ bán những mặt hàng có cùng thuế suất. Nó thường thuộc một trong các giá trị ( 5%, 10%, 20% hay 20%) tuỳ theo loại hàng hoá hay dịch vụ. Giá trị của thành phần này cũng yêu cầu người dùng nạp vào và có thể kiểm tra tính hợp lý bằng cách xét xem nó có thuộc một trong các giá trị nêu trên. Giá trị mặc nhiên nên chọn giá trị thuế suất của chủng loại mặt hàng nào mà công ty thường kinh doanh. Mỗi lần nạp vào hay thay đổi giá trị của thành phần này thì phải xác định lại giá trị của các thành phần thứ 21, 22 và 23. Trong đó (21)= (19)x Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 125
32. Giáo trình: Phân tích & thiết kế HTTT. (20), (22)=(19)+21) và (23)= đổi (22) thành chuỗi. Giá trị của thành 20 và 21 ứng với giá trị của thuộc tính T_TYLE và T_THUE tương ứng trong bảng T_TEMP1. Thành phần thứ 24: ứng với thông báo “Lưu và in” như ý nghĩa của nó. Đây là một nút chức năng, nó bị vô hiệu hoá khi chưa xác định một hoá đơn, chẳng hạn khi chưa tồn tại mã số cửa hàng hay mã số khách hàng hay phải có ít nhất một mặt hàng được bán. Khi nó có hiệu lực (tức các điều kiện xác định hoá đơn được thõa) và nếu này được chọn hệ thống phải thực hiện công việc lưu những nội dung của hoá đơn đã cập nhật trên màn hình vào cơ sở dữ liệu và in hoá đơn nếu cần. Tuy nhiên việc đưa những gì có trên màn hình vào cơ sở dữ liệu gồm nhiều thao tác. Trước hết phải định vị trong bảng T_PH có F_PSO bằng giá trị của thành phần 1. Nếu điều đó là tồn tại thì chỉ cần lấy toàn bộ dữ liệu của bảng T_TEMP1 ghi đè lên bộ đã định vị. Trong trường hợp không tồn tại một bộ như vậy thì có thể bổ sung một bộ mới bằng giá trị của bảng T_TEMP1 vì cấu trúc của hai bảng này là như nhau. Đối với bảng T_NX cũng thực hiện tương tự. Do cấu trúc của bảng T_TEMP2 và của T_NX không hoàn toàn giống nhau nên các cột F_TENHH, F_DVT trong bảng T_TEMP2 không được đưa vào, nhưng thuộc tính F_PSO lại không có trong cấu trúc của bảng T_TEMP2 nên giá trị của nó lấy giá trị của thành phần thứ 1 chung cho mọi mặt hàng có trên hoá đơn. Chú ý là việc đưa vào phải tiến hành tuần tự và chỉ đối với những bộ trong bảng T_TEMP2 có giá trị của thuộc tính F_MAHH mà thôi. Những bộ không tồn tại giá trị của thuộc tính F_MAHH sẽ bị bỏ qua. Trong trường hợp nhiều người sử dụng cùng thao tác lập hoá đơn bán hàng thì phải kiểm soát chặt chẽ, tránh việc ghi chồng không cố ý bằng cách khi chọn chức này phải cố gắng tạm chiếm độc quyền trên hai bảng T_PH và T_NX, chừng nào ghi xong mới gỡ khoá để người dùng khác thực hiện. Chúng ta có thể mô tả hình thức thực hiện chức năng Lưu và in như sau: T_PH F_MAK F_PSO F_NLAP F_MACH F_TYLE F_THUE H BHH01 BHH02 BHH03 BHH04 BHH19 11-09-06 03 071056 10% BHH20 11-09-06 03 071089 10% Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 126
33. Giáo trình: Phân tích & thiết kế HTTT. T_NX F_PSO F_MAHH F_SL F_DG F_ST BHH19 A 10 200 2000 BHH19 B 20 300 6000 BHH19 C 10 100 1000 BHH19 D 30 500 15000 BHH19 E 60 150 9000 BHH19 F 70 400 28000 BHH19 G 10 300 3000 BHH20 I 10 200 2000 BHH20 J 20 300 6000 BHH20 K 10 100 1000 BHH20 L 30 500 15000 BHH20 M 60 150 9000 BHH20 N 70 400 28000 Mỗi chức năng ghi nhận dữ liệu trong các hoạt động của hệ thống thông tin phải được thể hiện bởi một màn hình cập nhật dữ liệu. Những dữ liệu đưa vào hệ thống thông tin phải được kiểm soát chặt chẽ cho nên các chức năng của màn hình thực hiện các chức năng trên phải được thiết kế và kiểm tra kỹ trước khi chuyển cho bộ phận lập trình. Người ta thường mô tả tài liệu thực hiện. Tên dự án: Tên tài liệu: màn hình giao diện Số thứ tự ô xử lý: . Ngày lập: . Phiên bản: Trang: Các thao tác trên giao diện Tên thao tác Đặc tả Chức năng Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 127
34. Giáo trình: Phân tích & thiết kế HTTT. 7. THIẾT KẾ CÁC KẾT XUẤT (THIẾT KẾ ĐẦU RA) 7.1. Nội dung kết xuất Nội dung kết xuất là những thông tin được xử lý từ tất cả những dữ liệu, nó có thể chỉ đơn thuần lấy từ dữ liệu gốc và các dữ liệu cơ sở, nhưng có khi phải qua quá trình tính toán, tổng hợp rất phức tạp mới có. Điều này đòi hỏi người thiết kế phải am hiểu và trình bày chính xác giải thuật giải quyết vấn đề. Kết xuất là một hệ thống con, nó lấy dữ liệu có được từ những chức năng cập nhật dữ liệu hoặc qua những chức năng xử lý biến đổi trước đó. Bảo đảm dữ liệu cho một kết xuất chính xác đòi hỏi phải có cách thức tổ chức và quản trị chặt chẽ gọi là kiểm soát quá trình. Khi đã bảo đảm tất cả các dữ liệu và điều kiện để thực hiện các kết xuất thì chức năng này mới được cho phép. Nhiều xử lý mà điều kiện thực thi được kiểm soát nghiêm ngặt, có thể vì tính bảo mật của hệ thống thông tin, cũng có khi do tính nguy hại nếu thực thi sai quy trình. Thí dụ chức năng tạo số báo danh và sắp xếp phòng thi trong hệ thống tuyển sinh. Nếu sau khi đã thực hiện chức năng này và thực hiện các công việc in cũng như gửi giấy báo dự thi đến tất cả các thí sinh, nếu sau đó có một sự điều chỉnh liên quan tới họ tên thí sinh hay phòng thi mà thực thi lại chức năng này thì toàn thể những gì liên quan tới số báo danh và phòng thi đã thông báo với thí sinh bị sai lệch có thể dẫn tới việc huỷ bỏ một đợt thi, thiệt hại vật chất và công sức sẽ rất lớn. Thí dụ: hạch toán giá vốn theo phương pháp nhập trước xuất trước, xác định nợ quá hạn, thống kê dữ liệu tuyển sinh ƒ Xác định đối tượng dùng kết xuất: bên trong hay bên ngoài hệ thống thông tin. ƒ Hình thức trình bày kết xuất: thường do những người khai thác hệ thống thông tin đòi hỏi. Đây là tài liệu/vật chứng quan trong cho người phân tích và thiết kế làm căn cứ trong quá trình xây dựng Hệ thống thông tin. ƒ Cách thức trình bày kết xuất. ƒ Phương tiện kết xuất: màn hình / máy in / tập tin. ƒ Số lượng dữ liệu hiện diện trên kết xuất. 7.2. Hình thức trình bày Biểu bảng: Biểu bảng là hình thức phổ biến nhất. Hình thức này thích hợp với kết xuất nhiều dữ liệu, thường có phân loại, sắp xếp, có thể có tổng hợp, không bình luận, nhận xét. Đặc điểm của hình thức này là thời gian in kết xuất lớn. Yêu cầu là các biểu bảng phải thoáng, dễ đọc. Dạng biểu đồ: Biểu đồ thường được dùng khi người khai thác cần so sánh các dữ liệu, không cần chính xác tuyệt đối để đánh giá khuynh hướng phát triển. Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 128
35. Giáo trình: Phân tích & thiết kế HTTT. Màu sắc: Cần chú ý một số màu sau có những ý nghĩa cụ thể: • Màu đỏ - cảnh báo hoặc ngăn cấm. • Màu cam hoặc màu hường - gây chú ý. • Màu xanh - bình thường. 7.3. Phương tiện kết xuất Phương tiện kết xuất thường là màn hình hoặc ra giấy thông qua các thiết bị in hoặc kết hợp cả hai phương tiện. Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 129
36. Giáo trình: Phân tích & thiết kế HTTT. BÀI TẬP Với các bài tập sau đây yêu cầu người học phải xây dựng các mô hình thực thể - kết hợp, lưu đồ dòng dữ liệu, mối liên quan giữa hai mô hình trên, chuyển từ mô hình thực thể kết hợp thành mô hình quan hệ. 1. ĐĂNG KÝ MÔN HỌC VÀ HỌC PHÍ Một trường đại học có nhu cầu tin học hóa khâu quản lý việc đăng ký môn học và học phí của sinh viên. Một sinh viên sau khi hoàn thành thủ tục nhập học phải cho biết họ và tên, ngày sinh, giới tính, quê quán gồm tên huyện và tên tỉnh. Nếu sinh viên thuộc đối tượng (con liệt sỹ, con thương binh, con gia đình có công với nước, có hộ khẩu tại vùng sâu, vùng xa, ) thì phải có xác nhận của địa phương. Mỗi đối tượng có một tỷ lệ tương ứng về việc giảm học phí. Để thuận tiện trong việc quản lý người ta gán cho mỗi sinh viên một mã số gọi là mã số sinh viên, mã số này là duy nhất, không thay đổi trong suốt quá trình sinh viên học tại trường. Căn cứ ngành học mà sinh viên thi đậu vào mà sinh viên đó sẽ thuộc sự quản lý của một khoa nào đó: nghĩa là mỗi sinh viên thuộc một ngành, và một khoa có thể gồm nhiều ngành học khác nhau; dĩ nhiên không tồn tại một ngành thuộc sự quản lý của hai khoa khác nhau. Vào đầu học kỳ mới sinh viên đến phòng Giáo vụ đăng ký các môn học. Việc đăng ký môn học được thể hiện qua một phiếu đăng ký. Trên phiếu đăng ký thông tin về sinh viên (mã số, họ và tên), ngày đăng ký, học kỳ và niên khóa đăng ký. Một phiếu đăng ký có thể có nhiều môn học (mã môn, tên môn và số đơn vị học trình tương ứng của môn đó). Tất nhiên là các môn học đó sẽ được dạy trong học kỳ cho sinh viên đăng ký mà phòng Giáo vụ đã có kế hoạch trong thời khóa biểu đã thông báo cho sinh viên biết trước khi đăng ký. Mỗi môn học ngoài việc định danh bằng tên còn kèm theo số tín chỉ học trình và được gán cho một mã số môn học. Số tín chỉ của mỗi môn học tùy thuộc vào thời gian giảng dạy (thường 15 tiết lý thuyết hoặc bài tập hay 30 tiết thực hành tương đương 1 tín chỉ). Để đơn giản người ta phân thành hai loại môn: môn lý thuyết (hoặc bài tập) và môn thực hành. Nếu đăng ký môn lý thuyết sinh viên sẽ phải trả 27000 đồng/ tín chỉ, còn với môn thực hành là 37000 đồng/tín chỉ. Có một số môn, muốn đăng ký học, sinh viên phải học và đạt trên điểm trung bình một số môn trước để làm cơ sở cho việc học môn đó (gọi là các môn tiên quyết của môn học đó). Mỗi ngành học bao gồm một hệ thống nhiều môn mà sinh viên thuộc ngành đó phải theo học nằm trong nội dung chương trình giảng dạy của ngành đó; có thể có nhiều môn thuộc chương trình giảng dạy của nhiều ngành học khác nhau. Mỗi học kỳ, căn cứ vào việc đăng ký các môn học và đối tượng của từng sinh viên mà người ta xác định được số tiền học phí mà mỗi sinh viên sẽ phải đóng. Sau khi đăng ký xong các môn học, sinh viên phải đến Phòng Tài vụ của trường để đóng học phí. Mỗi lần khi một sinh viên đến nộp học phí, một phiếu thu được lập, trên đó ghi nhận mã số sinh viên, ngày lập, số tiền mà sinh viên đóng và được đánh số thứ tự để tiện việc theo dõi. Mỗi phiếu thu chỉ thu tiền học phí của một sinh viên tại một học kỳ. Một phiếu thu được in thành hai liên, một liên gửi cho sinh viên như một biên lai, liên còn lại để lưu. Nhân viên của Phòng Tài vụ lập phiếu phải nhận tiền học phí của sinh viên để cuối buổi nộp cho thủ quỹ. Mỗi học kỳ, nhà trường khống chế thời điểm cuối cùng (một ngày nào đó) mà sinh viên phải hoàn thành thủ tục trên, nếu quá Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 130
37. Giáo trình: Phân tích & thiết kế HTTT. hạn đó phòng Tài vụ khóa sổ không thu nữa, và như vậy những sinh viên không đóng, không kịp đóng hoặc đóng không đủ học phí sẽ không được tham dự kỳ thi cuối học kỳ đó. Mỗi học kỳ, sau khi cho sinh viên đăng ký môn học, để khuyến khích sinh viên đóng học phí sớm nhà trường cũng qui định một ngày mà nếu sinh viên đóng học phí trước ngày đó sẽ được giảm một tỷ lệ nào đó (thường là 5% số tiền học phí mà sinh viên phải đóng cho học kỳ đó). Mỗi học kỳ sinh viên có thể đóng học phí làm nhiều lần tùy theo tình hình tài chính của mình và phải đóng trước ngày hết hạn đóng học phí của học kỳ đó. Khi hết hạn đóng học phí Phòng Tài vụ sẽ tổng kết số tiền học phí mà mỗi sinh viên đã đóng, kết hợp với số tiền học phí mà sinh viên phải đóng xác định danh sách những sinh viên đang còn nợ học phí của học kỳ đó để gửi cho bộ phận quản lý của Phòng Giáo vụ loại những sinh viên đó ra khỏi danh sách dự thi. 2. QUẢN LÝ ĐỒ ÁN - NIÊN LUẬN Bộ môn Hệ thống thông tin và toán ứng dụng khoa Công Nghệ Thông Tin muốn quản lý tất cả các đồ án - niên luận của sinh viên tin học chính quy cũng như tại chức. Để dễ dàng trong việc quản lý, ngay sau khi vào trường mỗi sinh viên ngoài họ tên, ngày sinh, giới tính đều được gán một mã số gọi là mã số sinh viên. Sinh viên chính quy thuộc sự quản lý của trường còn đối với sinh viên tại chức sẽ thuộc sự quản lý của một đơn vị đào tạo (thường là trung tâm giáo dục thường xuyên) của một tỉnh nào đó. Trong chương trình đào tạo sinh viên phải thực hiện một số loại đồ án (niên luận 1 - lập trình chuyên ngành, niên luận 2 - lập trình quản lý, niên luận 3 – lập trình ứng dụng, tiểu luận tốt nghiệp, và luận văn tốt nghiệp cho một số sinh viên xuất sắc khi ra trường). Mỗi loại đồ án - niên luận có một số đơn vị học trình tương ứng gọi là số tín chỉ. Theo chương trình học, đến kỳ triển khai đồ án – niên luận bộ môn yêu cầu các giáo viên ra đề tài cho sinh viên chọn. Mỗi một đề tài giáo viên yêu cầu những điều mà sinh viên sẽ phải làm, cung cấp các tài liệu để sinh viên tham khảo. Sau khi giáo viên nộp đề tài bộ môn sẽ gán cho mỗi đề tài một mã số. Việc định danh (đặt tên) do các giáo viên ra đề tài quyết định. Mỗi đề tài chỉ thuộc một loại đồ án – niên luận duy nhất, và được ra bởi ít nhất một giáo viên trong bộ môn. Mỗi một giáo viên được nhận biết qua mã số giáo viên, họ tên, ngày sinh, phái và một chức danh. Mỗi chức danh có một hệ số chức danh, và căn cứ vào chức danh này để sau này tính tiền cho giáo viên ra đề tài hay giáo viên hướng dẫn đồ án – niên luận. Đến học kỳ mà sinh viên phải thực hiện loại đồ án nào đó, bộ môn sẽ triển khai việc thực hiện đồ án – niên luận cho sinh viên. Trước hết bộ môn cung cấp danh sách các đề tài mà các giáo viên đã ra thuộc loại đó để sinh viên lựa chọn thực hiện. Đối với các loại niên luận, tiểu luận, các sinh viên tự lập nhóm, tối đa hai sinh viên một nhóm, nhóm này chọn làm chung một quyển đồ án và một quyển đồ án như vậy làm về một đề tài duy nhất trong danh sách các đề tài được bộ môn cung cấp. Riêng trường hợp đối với luận văn tốt nghiệp, chỉ có một số sinh viên xuất sắc được chọn và mỗi sinh viên làm một đồ án tốt nghiệp riêng rẽ. Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 131
38. Giáo trình: Phân tích & thiết kế HTTT. Sau khi sinh viên lựa chọn đề tài, bộ môn sẽ phân công giáo viên hướng dẫn cho từng nhóm sinh viên làm chung một đề tài và viết chung một quyển đồ án - niên luận. Nói chung giáo viên ra đề tài là người hướng dẫn những sinh viên thực hiện đề tài đó, tuy nhiên có khi giáo viên ra đề tài bận đi công tác, bộ môn có thể cử người khác hướng dẫn. Đến hạn sinh viên phải hoàn thành và nộp các quyển đồ án. Quyển đồ án phải được soạn theo mẫu mà bộ môn đã quy định để dễ dàng trong việc quản lý và đánh giá. Cán bộ trực bộ môn phải chịu trách nhiệm thu nhận các quyển đồ án mà sinh viên nộp. Để đơn giản trong quản lý, mỗi quyển đồ án – niên luận được cán bộ trực bộ môn gán cho một số thứ tự, ghi nhận lại ngày mà sinh viên nộp. Ngay sau ngày hết hạn nộp trưởng hoặc phó bộ môn sẽ phân công giáo viên đánh giá và chấm điểm cho từng quyển đồ án. Bộ môn cũng yêu cầu các giáo viên nộp kết quả đúng kỳ hạn để tổng kết điểm. Các sinh viên thực hiện chung một đề tài sẽ được chung một điểm kết quả qua sự cho điểm đó. Khi đến hạn, bộ môn sẽ tổng kết điểm, lập danh sách báo cáo cho phòng Giáo vụ. Cuối học kỳ bộ môn tổng kết số đề tài mà mỗi giáo viên đã ra (mà được sinh viên chọn làm đồ án – niên luận), số đồ án – niên luận mà mỗi giáo viên đã hướng dẫn, đã chấm để làm cơ sở cho việc tính tiền giảng dạy. Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 132
39. Giáo trình: Phân tích & thiết kế HTTT. 3. QUẢN LÝ CÔNG TÁC GIẢNG DẠY – CỐ VẤN HỌC TẬP Một trường Đại học muốn quản lý công tác giảng dạy của cán bộ. Trường có nhiều khoa, mỗi khoa chịu trách nhiệm quản lý nhiều cán bộ giảng dạy. Phòng tổ chức đã quản lý phần lý lịch của từng người, tuy nhiên trong công tác người ta quan tâm đến một số thuộc tính phổ biến sau: mã số cán bộ, họ tên cán bộ, và chức danh. Chức danh giảng dạy là một cơ sở để thanh toán tiền giảng dạy cho giáo viên, mỗi một chức danh có một hệ số chức danh tương ứng. Ngoài việc giảng dạy chính quy trong trường, các cán bộ còn có thể đảm nhận giảng dạy ở các đơn vị đào tạo khác của các tỉnh hoặc thành phố khác. Người ta nhận biết mỗi lớp nhờ ngành, khóa và tên đơn vị đào tạo. Thí dụ “Tin học 95 Vĩnh Long” – lớp thuộc hệ tại chức, “Sư phạm Toán 20” – lớp thuộc hệ chính quy Mỗi lớp chỉ thuộc một hệ, các lớp tại trường thuộc hệ chính quy, các lớp ngoài trường thuộc hệ tại chức. Mỗi một học kỳ của một năm học nào đó, một cán bộ có thể dạy nhiều môn cho nhiều lớp và cũng có thể cùng một môn cho cùng một lớp, tại cùng một học kỳ đó có thể nhiều người cùng dạy với một số tiết tương ứng. Việc quy chuẩn 1 tiết dạy tùy thuộc vào tính chất của môn học. Các môn lý thuyết hoặc môn bài tập mỗi tiết tương đương một tiết chuẩn, nhưng đối với các môn thực hành, mỗi tiết bằng ½ tiết chuẩn. Căn cứ vào số lượng sinh viên học mà giáo viên dạy cho lớp đó được hưởng một hệ số trong giảng dạy, lớp càng đông thì hệ số giảng dạy càng cao, chẳng hạn nếu sỹ số lớp ít hơn 80 thì hệ số bằng 1, nếu sỹ số lớp từ 80 tới 139 thì hệ số bằng 1, 2, nếu sỹ số từ 140 đến 179 thì hệ số bằng 1, 5, ; hệ số này là cơ sở để tính số tiết chuẩn trong giảng dạy. Việc ra đề tài, hướng dẫn và đánh giá (nhận xét và cho điểm) đồ án – niên luận cũng là nhiệm vụ của cán bộ giảng dạy. Theo quy định thì việc hướng dẫn đồ án niên luận tùy thuộc vào số tín chỉ của loại đồ án – niên luận. Mỗi loại đồ án - niên luận tương đương với một số tín chỉ tương ứng: niên luận 1, 2, 3 tương đương 2 tín chỉ, tiểu luận tốt nghiệp 4 tín chỉ và luận văn tốt nghiệp 12 tín chỉ. Giáo viên hướng dẫn mỗi đề tài hưởng 2 tiết chuẩn/1 tín chỉ, với tiểu luận tốt nghiệp thì ngoài số tiết cho giáo viên hướng dẫn, người đọc và nhận xét cũng được hưởng 3 tiết / quyển đồ án tốt nghiệp, với luận văn tốt nghiệp thì giáo viên phản biện được hưởng 5 tiết / quyển. Ngoài công tác giảng dạy, mỗi giáo viên có thể có thể làm cố vấn học tập của một lớp học chính quy nào đó. Tại mỗi học kỳ, một lớp chỉ có một giáo viên làm cố vấn học tập. Giáo viên làm cố vấn học tập một lớp được hưởng 20 tiết / học kỳ. Cuối năm mỗi giáo viên kê khai khối lượng công tác trong học kỳ đó, trưởng hoặc phó bộ môn kiểm tra, điều chỉnh để báo cho bộ phận giáo vụ làm cơ sở tính tiền giảng dạy cho từng người. Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 133
40. Giáo trình: Phân tích & thiết kế HTTT. Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 134
41. Giáo trình: Phân tích & thiết kế HTTT. 4. QUẢN LÝ NHÀ HÀNG KHÁCH SẠN “ Paradis” Thiên đường là một khách sạn cỡ lớn nhiều phòng, một nhà hàng bán đồ ăn, thức uống, một sàn nhảy và một phòng giải trí. Doanh số đạt được nhờ cho thuê phòng và bán đồ ăn, thức uống. Ban giám đốc đặc biệt bận tâm về công việc của Phòng tiếp tân. Chính là ở khâu này mà khách liên hệ đặt chổ, tìm phòng thuê, nhận chìa khóa phòng, đặt tiệc, yêu cầu dịch vụ (giặt ủi, dọn phòng, tham quan, ) và thanh toán tiền lúc rời khách sạn. Khách đặt chổ phải liên hệ với nhân viên của phòng tiếp tân, nhân viên này phải phân tích yêu cầu của khách và tham khảo hồ sơ dành chổ và hiện trạng của kháh sạn để giải quyết yêu cầu của khách. Cần phải biết khách có bao nhiêu người, từ ngày nào đến ngày nào, khách cần phòng hạng nào (phòng hạng sang hay phòng bình dân), có yêu cầu gì đặc biệt không? để dành chổ cho khách nếu đến thời điểm khách đến còn phòng trống (phòng chưa ai đặt chổ hoặc không còn khách ở). Khi khách hàng đến: Đa số khách đến khách sạn đã có dành chổ trước (hoặc nhờ hướng dẫn viên du lịch dành chổ). Số còn lại đến thuê ngay, với hy vọng còn thuê được phòng để thuê. Khi khách hàng đến, nhân viên tiếp nhận sẽ hỏi xem vị khách đó có dành chổ trước hay không, và danh trước với tên nào. Như vậy cần phải tham khảo đến hồ sơ dành chổ trước. Đôi khi khách cứ khăng khăng đã có dành chổ, trong khi thật ra không có. Khi khách đến không dành chổ trước, nhân viên tiếp nhận phải xem còn phòng trống hay không. Nếu không, nhân viên này phải thông báo cho khách biết tên một số khách Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 135
42. Giáo trình: Phân tích & thiết kế HTTT. sạn khác có khả năng còn phòng. Nếu có phòng đáp ứng yêu cầu của khách nhân viên tiếp tân yêu cầu khách xuất trình giấy tờ và giữ lại chứng minh nhân dân hay giấy tờ tùy thân khác (nếu khách không có chứng minh nhân dân). Giấy tờ này sẽ trả lại khi khách hoàn thành thủ tục rời khách sạn. Mỗi căn phòng, tùy theo kiểu, vị trí và những tiện nghi bố trí bên trong mà có một giá biểu riêng. Khi khách đến thuê, nhân viên tiếp tân phải ghi nhận phiếu đến. Mỗi phiếu đến chỉ lập cho một người khách, thường là người chịu trách nhiệm thanh toán sau này. Trên phiếu đến cần phải ghi rõ khách nào được bố trí ở phòng nào, vào khoảng thời gian nào (ngày nào) để thuận tiện trong việc khai báo tạm trú, tạm vắng khi nhà chức trách đến kiểm tra. Nhân viên tiếp nhận cho biết giá phòng của từng người hoặc cả nhóm (nếu nhóm đi chung, mướn nhiều phòng và trả tiền chung). Nếu khách có yêu cầu dịch vụ (giặt ủi, gọi điện thoại, karaoke, ), nhân viên tiếp tân phải lập một bảng kê. Mỗi bảng kê có một số thứ tự và lập cho một khách, ghi tất cả những dịch vụ mà khách yêu cầu trong suốt quá trình lưu trú tại khách sạn. Trong đó phải ghi chi tiết khách yêu cầu dịch vụ gì vào thời điểm nào, chi phí tương ứng là bao nhiêu. Bảng kê chi phí này nhân viên tiếp tân giữ lại và sẽ yêu cầu khách thanh toán khi rời khỏi khách sạn sau đợt nghỉ. Nếu khách có yêu cầu đặt tiệc tùng, nhân viên tiếp tân phải lập một hóa đơn. Trên hóa đơn ghi nhận những món mà khách yêu cầu. Qua hóa đơn đó thể hiện các yêu cầu của khách (số lượng, thẩm mỹ, cách và thời gian bày trí, ) và từ đó nhân viên tiếp tân thõa thuận với khách đơn giá tương ứng cho từng món. Một bản sao hóa đơn được giao cho nhà hàng để bộ phận phục vụ chuẩn bị. Mỗi hóa đơn có một số thứ tự và ghi cho chỉ một khách hàng. Khách hàng có thể thanh toán hóa đơn ngay hoặc bộ phận tiếp tân giữ lại yêu cầu khách trả sau này. Cuối ca làm việc nhân viên tiếp tân phải bàn giao hồ sơ cho nhân viên làm việc ca kế những hồ sơ, trao đổi những công việc còn tồn đọng cần phải giải quyết, nộp hết những số tiền mà khách đã thanh toán cho thủ quỹ. Khi khách đi: Mọi thủ tục cũng diễn ra ở Phòng tiếp tân. Lúc đó, phiếu đến, bảng kê dịch vụ và hoá đơn tiệc tùng chưa thanh toán là cơ sở yêu cầu khách phải trả. Bộ phận phục vụ kiểm tra các phòng mà khách đã ở xem có hư hao gì không và xác nhận vào phiếu đến. Nếu khách làm hư hại đồ đạc trong phòng thì khách phải đền bù hoặc trả thêm tiền để khách sạn sắm sửa lại. Khi khách trả tiền một phiếu thu được lập. Mỗi phiếu thu có một số thứ tự, thu tiền của chỉ một khách hàng, ngày thu, lý do (thu của phiếu đến, bảng kê và các hoá đơn nào) với số tiền thu là bao nhiêu. Nhân viên tiếp tân lập hóa đơn chịu trách nhiệm nhận tiền khách hàng, ký xác nhận vào phiếu thu, và lập thành hai liên một liên giữ lại, còn một liên giao khách hàng. Ban Giám Đốc muốn tin học hóa các công việc: dành chổ trước, theo dõi sự lưu trú, yêu cầu dịch vụ, đặt tiệc và thanh toán của khách hàng. Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 136
43. Giáo trình: Phân tích & thiết kế HTTT. 5. TỔ CHỨC HỘI THẢO KHOA HỌC Ban tổ chức một hội thảo khoa học quốc tế muốn tin học hóa các công việc của mình để kịp thời theo dõi hàng ngày tình hình đăng ký tham dự hội thảo, tình hình các báo cáo khoa học gởi đến, tình hình các báo cáo được xét duyệt, in ấn, tình hình thanh toán lệ phí tham dự và quản lý lịch báo cáo. Ban tổ chức chia ra làm bộ phận: ban phụ trách chương trình hội thảo, ban phụ trách đăng ký tham dự hội thảo và ban thư ký. Ban PhỤ Trách Đăng Ký Tham DỰ HỘi ThẢo Ban sẽ lập một danh sách các cơ quan trong nước và ngoài nước để sau này ban thư ký gởi thông báo hội thảo. Những người muốn tham dự phải điền vào phiếu đăng ký và gởi bưu điện đến cho ban tổ chức hoặc liên hệ trực tiếp bằng điện thoại với ban phụ trách đăng ký. Nhưng để được thực sự tham dự thì phải đóng đủ lệ phí của cuộc hội thảo. Người đăng ký có thể đóng tiền trực tiếp (khi đó một phiếu thu được lập) hoặc chuyển khoản vào tài khoản của cuộc hội thảo. Đối với những người nào thanh toán lệ phí bằng tiền mặt ban phụ trách đăng ký sẽ đưa họ ngay vào danh sách người tham dự hội thảo. Đối với những người thanh toán lệ phí bằng chuyển khoản, ban phụ trách sẽ ghi họ vào một danh sách khác (danh sách những người tham dự chờ thanh toán lệ phí), và đợi cho đến khi ngân hàng gởi giấy báo rằng số tiền đã thực sự đưa vào tài khoản của ban tổ chức hội thảo, thì tên họ mới được đưa vào danh sách những người tham dự hội thảo. Cuối cùng ban sẽ lập danh sách những người tham dự chính thức để chuyển qua cho ban thư ký. Tất cả những người muốn tham dự hội thảo đều phải làm thủ tục trên và đóng lệ phí đầy đủ, kể cả những người sẽ báo cáo tại hội nghị. Ban Thư Ký Ban thư ký có nhiệm vụ phục vụ cho ban phụ trách đăng ký và ban phụ trách chương trình. Sau đây là những công việc của ban thư ký: - Gởi tờ thông báo hội thảo theo danh sách cho ban phụ trách đăng ký chuẩn bị. Tờ thông báo ghi những tin sau: các chuyên đề của hội thảo, địa chỉ, số điện thoại, số tài khoản ngân hàng của ban tổ chức, tên của người trưởng ban tổ chức chung, tên của người trưởng và các thành viên của ban phụ trách chương trình, tên của người trưởng ban phụ trách đăng ký tham dự, tên vủa người trưởng ban thư ký, thời hạn đăng ký tham dự, thời hạn gởi báo cáo khoa học đến để xét chọn. Tờ thông báo có kèm theo một phiếu đăng ký gồm các khoản phải đền là họ tên, địa chỉ liên lạc, tên cơ quan làm việc, có dự định báo cáo hay không, và phương tiện thanh toán (tiền mặt, chuyển khoản). Gởi các báo cáo cho các phản biện theo yêu cầu của ban phụ trách chương trình. Trong thư gởi có ghi rõ thời hạn các phản biện phải gởi trã về. Nhận các bản nhận xét và phiếu điểm cùng bản báo cáo do các phản biện gởi trả về và chuyển cho ban phụ trách chương trình. Đánh thư thông báo và gởi cho các tác giả của các bản báo cáo được ban phụ trách chương trình xét chọn. Trong thư có yêu cầu các tác giả soạn sẵn báo cáo thành file theo qui cách (kích cở, font chữ) do ban thư ký qui định (để sau này tiện việc in ấn tập kỷ yếu hội thảo) và thời hạn các tác giả gởi trả về ban thư ký. Tổ chức việc in ấn tập kỷ yếu hội thảo. Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 137
44. Giáo trình: Phân tích & thiết kế HTTT. In chương trình chi tiết các buổi hội thảo (do ban phụ trách chương trình cung cấp), in danh sách chính thứcnhững người tham dự hội thảo. Chuẩn bị hồ sơ cho mỗi người tham dự hội thảo để phát cho họ vào ngày đầu tiên. Hồ sơ gồm một bản chương trình, một bản danh sách chính thức những người tham dự hội thảo, một tập kỷ yếu và một ít giấy trắng để ghi chép. Ban Phụ Trách Chương Trình Ban phụ trách chương có nhiệm vụ xây dựng danh mục các chủ đề của hội nghị, mời một số nhà khoa học phản biện các báo cáo, để dễ dàng chọn những người phản biện sau này, mỗi người phản biện được ban phụ trách xếp vào chủ đề phù hợp với chuyên môn của người phản biện đó. Các tác giả gởi báo cáo làm 3 bản đến ban phụ trách chương trình. Mỗi tác giả được quyền gởi tối đa 2 báo cáo nhưng chỉ có một báo cáo là tác giả chính (trong trường hợp đồng tác giả, tác giả ghi đầu tiên được xem là tác giả chính). Khi hết hạn nộp báo cáo, ban phụ trách chương trình xét duyệt sơ bộ, loại ngay những báo cáo ngoài chủ đề của hội nghị, và xếp sơ bộ mỗi báo cáo vào một chủ đề duy nhất. Công việc xếp sơ bộ này nhằm giúp ban phụ trách chương trình dễ dàng chọn người phản biện. Các phản biện sẽ phải ghi nhận xét của mình trên một tờ nhận xét do ban phụ trách chương trình gởi đến, và cho điểm (điểm 0 không chấp nhận báo cáo, điểm từ 1 đến 4: báo cáo được đề nghị chọn, điểm càng cao khả năng được chọn càng lớn). Việc cho điểm sẽ giúp ban phụ trách chương trình dễ dàng chọn lựa khi có nhiều báo cáo trong cùng một chuyên đề đều được đề nghị chọn. Thời hạn các phản biện gởi nhận xét là thời hạn áp dụng chung cho tất cả các phản biện. Sau khi đã chọn chính thức cáo báo cho hội thảo, ban phụ trách chương sẽ lập danh sách cáo báo được chọn để gởi qua cho ban thư ký, đồng thời lên lịch hội thảo (nghĩa là xếp các báo vào các chuyên đề chính thức, xếp các chuyên đề vào cáo buổi, ngày, phòng, và quyết định một người trách nhiệm điều khiển các buổi hội thảo của cùng một chủ đề). Một buổi hội thảo diễn ra trong một ngày, một buổi (sáng hoặc chiều), một phòng và liên quan đến một chủ đề, ban phụ trách chương trình có thể xếp vào nhiều buổi hội thảo, nếu có một lượng lớn các báo cáo được chọn xếp cho chủ đề đó. Để người tham dự dễ nhớ phòng, các buổi hội thảo của cùng một chủ đề luôn được xếp vào cùng một phòng. Trong cùng một ngày và cùng một buổi có thể diễn ra nhiều buổi hội thảo song song liên quan đến những chủ đề khác nhau. Đối với những báo cáo không được chọn, ban phụ trách chương trình gởi trả tác giả hết cả 3 bản cùng với 2 bản nhận xét (không kèm điểm) của các phản biện. Đối với các phản biện chưa gởi nhận xét, sau khi hết hạn một tuần, ban phụ trách chương trình sẽ bố trí cho người đến tận nơi đòi. 6. QUẢN LÝ LƯƠNG SẢN PHẨM Một công ty sản xuất muốn quản lý tiền lương của tất cả các nhân viên. Các nhân viên thuộc hai loại: nhân viên hành chánh và công nhân. Mỗi một nhân viên có một mã số, họ tên, phái, ngày sinh, và ngày bắt đầu tham gia công tác. Mỗi nhân viên sẽ thuộc một đơn vị quản lý nào đó. Công ty chịu trách nhiệm sản xuất ra các sản phẩm. Các sản phẩm này thường được khách hàng (thường là các công ty khác) đặt hàng thông qua một hợp đồng. Mỗi hợp đồng thường đặt nhiều sản phẩm với một số lượng và đơn giá tương ứng cùng những Biên soạn: Ths. Đinh Khắc Quyền & ThS. Phan Tấn Tài. 138