5.2.1. Xác định các điểm hở yếu
Điểm hở yếu là những điểm mà tại đó thông tin của công ty có tiềm năng bị thâm nhập bởi những người trong hoặc ngoài tổ chức. Điều này không chỉ nói tới dạng đầu ra, như đơn mua hàng và bảng kiểm kê, mà còn nói tới mọi hệ thống bên trong của công ty mà nếu bị dùng sai thì có thể làm cho tài sản của công ty chịu rủi ro.
Một số nơi thường có điểm hở
• Thông tin trên đường truyền từ nơi lưu trữ đến nơi sử dụng. Đó là dòng dữ liệu trên DFD đi tới một tác nhân ngoài để biểu thị thông tin ra, hay mọi dòng dữ liệu chuyển từ phần máy tính sang phần người sử dụng.
• Thông tin trao đổi qua giao diện. Nếu nhà thiết kế thiết kế giao diện không chuẩn việc sai lệch thông tin hệ thống hoạt động sai thất thoát tài sản của công ty, đây là tiềm năng mang một trong các mỗi nguy hiểm nhất.
• Các nơi lưu trữ thông tin (dữ liệu và phần mềm). Đó là kho dữ liệu hoặc tệp
5.2.2. Xác định các kiểu đe dọa
a. Các kiểu đe dọa thường gặp
Có năm kiểu đe dọa cơ bản
- Ăn cắp: bao gồm các hành vi phá hoại , hay các hành vi cố ý làm sai lệch dữ liệu. Khi tìm kiếm các kiểm soát trong phần hệ thống làm việc trên máy tính thì phần tài sản của công ty còn bị hở chính là thông tin, và rõ ràng nhóm kiểm soát phải thẩm tra các khả năng thông tin bị đánh cắp.
- Thất thoát tài sản: làm sai lệch, hư hỏng thông tin, đây là hành động vo tình. - Sai sót từ hệ thống: thể hiện ở hoạt động của hệ thống. Nhóm phân tích kiểm soát phải xem xét kỹ toàn bộ vấn đề độ chính xác của các chương trình máy tính và phải tính đến những nguy hiểm nếu như hệ thống máy tính hoạt động không đúng đắn. Đây là một trong những khía cạnh rất quan trọng trong việc nghiên cứu phân tích các kiểm soát.
- Phí tổn quá đắt: bao gồm các tiến hành các thủ tục của công ty theo một cách thực quá tốn kém không cần thiết.
công ty, của những người có thể được lợi do việc biết thông tin đó. Đây là một hoạt động bất hợp pháp.
b. Các mặt cần xem xét của một đe dọa
Bước 1. Xác định các trạng thái đe dọa (Khi nào? Tình trạng nào?)
Bước 2. Xác định các mức độ thiệt hại để đánh giá được mức độ thiệt hại mà tổ chức phải chịu. Cao: tác động trầm trọng cho tổ chức. Chẳng hạn như mất bí quyết kinh doanh. Vừa: có thiệt hại lớn, nhưng không ảnh hưởng đến toàn bộ tổ chức. Chẳng hạn như, sửa số liệu tồn kho để ăn cắp tài sản. Bình thường: thiệt hại có thể sửa chữa được. Chẳng hạn như sai số liệu cập nhật chứng từ.
Xét ví dụ về "Lập đơn đặt hàng" ta thấy
- Mối đe dọa từ việc ăn cắp, hoặc thất thoát tài sản được xếp vào loại vừa. Bởi vì, giá trị tối đa của một đơn hàng đặc biệt có thể làm cho công ty đó bị thiệt hại lớn, nhưng không thể gây nguy hiểm cho toàn bộ công ty.
- Tương tự, mối đe dọa từ việc quyết định thiếu thông tin, hay phí tổn quá cao cũng được xếp vào loại vừa.
Ta có thể mô tả việc phân tích các mối đe dọa trong việc "Lập đơn hàng" bằng bảng như sau.
Mẫu phân tích kiểm soát Hệ cung ứng vật tư
Tên tệp ra: Đơn hàng
Mục đích: đặt mua vật tư từ nhà cung cấp Nội dung/mô tả:
Số hiệu đơn hàng, Tên và địa chỉ nhà cung cấp
Với mỗi mặt hàng được đặt: Mã hàng của nhà cung cấp, Mã hàng của công ty
Đe dọa Nguy
hiểm Tình trạng Luồng thông tin trên DFD Kiểm soát 1. Ăn cắp mặt hàng đã đặt 2. Thất thoát do thông báo Cao Thấp - Đơn hàng bị truy nhập trái phép - Hệ cấp phát bị truy nhập trái phép 1.2 1.4 Hệ mật khẩu giá trị duy nhất Hệ mật khẩu Tạo một quá
sai số lượng kho phải đặt lại. - Việc đặt hàng không đúng 1.1 trình ra báo cáo quản lý kho
5.3. XÁC ĐỊNH CÁC TRẠNG THÁI PHÁT SINH ĐE DỌA VÀ LỰA CHỌN GIẢI PHÁPKIỂM SOÁT HỆ THỐNG KIỂM SOÁT HỆ THỐNG
5.3.1. Xác định các trạng thái phát sinh đe dọa
Sau khi xác định được từng đe dọa có thể xáy ra liên quan đến từng điểm hở, nhóm phân tích cần phải cố gắng làm rõ hoàn cảnh xuất hiện mối đe dọa đó.
Bước 1. Với các đe dọa đã được xác định ở trên, nhóm phân tích sử dụng DFD để xác định tình huống đặc biệt mà có thể phát sinh các mối đe dọa đó.
Ví dụ. Với việc lập đơn hàng nếu người ta định dùng đơn hàng để thực hiện việc ăn cắp thì nhất định họ phải thực hiện một lần thâm nhập trái phép vào hệ thống để tạo dựng nên một đơn hàng về một loại vật tư nào đó. Việc thâm nhập này phải xuất hiện trong quá trình tạo ra đơn hàng, cho nên phải đưa vào đối thoại để lập đơn hàng. Mối đe dọa quyết định thiếu thông tin nói tới tình huống đơn mua hàng quá nhiều hoặc quá ít so với lượng có trong kho.
Bước 2. Đánh giá xác suất xảy ra đe dọa. Ta có thể phân ra thành 3 loại sau. Cao: có nghĩa là tình huống có thể xuất hiện một cách đều đặn và tương đối thường xuyên. Vừa: nghĩa là tình huống có thể xuất hiện nhưng không thường xuyên và không đều đặn. Thấp: có nghĩa là sự kiện hầu như không thể xuất hiện nhưng bao giờ cũng có khả năng đó.
Ví dụ. Trong việc lên đơn đặt hàng. Nguy cơ ăn cắp trong việc lên đơn đặt hàng do làm sai lệch các bản ghi máy tính là có xác suất thấp. Mối đe dọa "quyết định thiếu thông tin" cũng có thể xuất hiện trên cơ sở đều đặn nếu trong bộ trình có một nhược điểm nào đó. Điều này có thể được đánh dấu là có xác suất cao.
5.3.2. Lựa chọn giải pháp kiểm soát hệ thống
Sau khi nhóm phân tích đã xác định ra các mối đe dọa và tình huống chúng có thể xuất hiện thì họ có thể bắt đầu ra quyết định về các kiểm soát thực tại dùng cho từng tình huống. Bao gồm các công việc.
kiểm soát: về kỹ thuật, về tài chính. Chi phí hiệu quả: so sánh giữa chi phí bỏ ra và các điểm lợi thu lại.
- Câu hỏi phải trả lời được khi thực hiện yêu cầu trên. Điểm hở có cần kiểm soát không? Những đe dọa gì ở những điểm hở cần kiểm soát? Sử dụng biện pháp nào? Tổng chi phí cho kiểm soát?
BÀI 4. THIẾT KẾ DỮ LIỆU 5.1. TỔNG QUAN VỀ THIẾT KẾ DỮ LIỆU
5.1.1. Mục đích
Trong phần thiết kế tổng thể đã quan tâm đến dữ liệu nhưng đó chỉ là thiết kế logic, trong phần này chúng ta quan tâm đến thiết kế vật lý của dữ liệu.
Mục đích của thiết kế cơ sở dữ liệu (CSDL) là xây dựng CSDL từ biểu đồ cấu trúc dữ liệu có thông tin đầy đủ và cho phép truy cập nhanh.
5.1.2. Phương thức tiến hành
Đầu vào là biểu đồ cấu trúc dữ liệu (mô hình thực thể liên kết hay mô hình quan hệ).
Có hai phương thức tiến hành: Dựa trên hệ quản trị CSDL có sẵn mối quan hệ, có ngôn ngữ định nghĩa dữ liệu riêng cho phép khai báo cấu trúc dữ liệu. Sử dụng tệp: người dùng phải biết tổ chức tệp của mình. Các hệ quản trị tệp không giúp quản lý CSDL. Ví dụ Pascal, C,….
5.2. PHÂN TÍCH SỬ DỤNG DỮ LIỆU5.2.1. Nghiên cứu các yêu cầu truy nhập 5.2.1. Nghiên cứu các yêu cầu truy nhập
Các yêu cầu thông tin cho từng chức năng đã được xem xét trong sơ đồ luồng dữ liệu. Tuy nhiên, trong sơ đồ luồng dữ liệu lại không chỉ ra cách thức truy cập các kho dữ liệu. Ở đây ta cần chỉ ra cách thức truy cập dữ liệu bao gồm các thông tin đầu vào, truy cập tệp nào, sử dụng khóa nào, thao tác gì.
Ví dụ. Xét tiến trình "Lập phiếu đòi sách mượn quá hạn". Việc thực hiện tiến trình này đòi hỏi một số truy nhập tới một phần của lược đồ dữ liệu trong hệ thống quản lý thư viện.
Hình
• Yêu cầu 1: biết Số thẻ, yêu cầu tìm số Cá biệt các sách có, ngày trả, ngày hẹn trả
• Yêu cầu 2: biết Số thẻ, yêu cầu tìm Tên bạn đọc và Địa chỉ bạn đọc.
• Yêu cầu 3: biết Số các biệt, yêu cầu tìm Tên sách, Tác giả, Nhà xuất bản và Năm xuất bản.
Phân tích và xây dựng các biểu đồ sử dụng dữ liệu cho các yêu cầu Xét yêu cầu 1:
• Bảng dữ liệu: MƯỢN/TRẢ
• Khóa tìm kiếm: Số thẻ
• Tra cứu: Số thẻ, Ngày trả, Ngày hẹn trả
• Tần suất truy nhập: 50 lần/tuần Xét yêu cầu 2:
• Bảng dữ liệu: BẠN ĐỌC
• Khóa tìm kiếm: Số thẻ
• Tra cứu: Tên bạn đọc, Địa chỉ
• Tần suất truy nhập: 50 lần/tuần Xét yêu cầu 3:
• Bảng dữ liệu: SÁCH
• Khóa tìm kiếm: Số các biệt
• Tra cứu: Tên sách, Tác giả, Nhà xuất bản, Năm xuất bản
• Tần suất truy nhập: 50 lần/tuần
5.2.2. Đánh giá không gian lưu trữ
Số lượng các bản ghi trong mỗi bảng dữ liệu được gọi là dung lượng của bảng dữ liệu. Thông tin này cần được bổ sung vào mô tả bảng.
Tuy nhiên trong thực tế, số lượng các bản ghi thường biến động. Chúng có thể tăng lên theo thời gian, hoặc đôi khi lại bị giảm đi. Thông thường, người ta ghi số lượng
trung bình trong một khoảng thời gian nào đó ứng với một chu trình hoạt động của hệ thống.
Trong ví dụ với mô hình thư viện vừa xét, người ta thường lấy chu kỳ thời gian là một năm: sau một năm thẻ bạn đọc thường được xem xét để gia hạn, đầu năm thường được xét cấp kinh phí để mua sắm sách, cuối mỗi năm thanh lý sách cũ, xử lý sách quá hạn lâu ngày, xử lý bạn đọc có nhiều sách quá hạn.
Việc tính toán, ước lượng dung lượng của các bảng dữ liệu có ảnh hưởng lớn tới việc lựa chọn thiết bị lưu trữ sau này.
5.3. CHUYỂN MÔ HÌNH DỮ LIỆU THÀNH TỆP DỮ LIỆU5.3.1. Thiết kế cơ sở dữ liệu vật lý 5.3.1. Thiết kế cơ sở dữ liệu vật lý
Thiết kế cơ sở dữ liệu là tiến trình tạo ra các định nghĩa dữ liệu cho hệ thống và thiết lập cấu trúc các tệp dữ liệu chính trong hệ thống. Trong tiến trình thiết kế cơ sở dữ liệu vật lý người ta thường phải sử dụng các thông tin về những ràng buộc thực hiện như môi trường phần cứng, phần mềm của người sử dụng, thời gian đáp ứng các yêu cầu, điều kiện kiểm soát, và điều kiện an toàn của hệ thống.
Ngoài ra, các chi tiết về phân tích và sử dụng dữ liệu như mô hình quan hệ, sơ đồ dòng dữ liệu hệ thống cũng cần thiết cho quá trình thiết kế cơ sở dữ liệu vật lý. Thông thường, bước đầu người ta chuyển đổi mô hình dữ liệu logic thành tập hợp ban đầu các tệp phù hợp với phần mềm được chọn để xử lý. Tiếp theo,thực hiện tối ưu hóa các tệp này cho đến khi đạt các yêu cầu về tính hiệu quả của hệ thống.
Khi thiết kế cơ sở dữ liệu vật lý nhà thiết kế phải lưu ý về an toàn và toàn vẹn dữ liệu.
- Tổ hợp được các kiểm tra an toàn và toàn vẹn cần thiết bên trong bản thân cơ sở dữ liệu. Các yêu cầu cho những điều này có thể đã được xac định ngay trong bước phân tích ban đầu, nhưng nó được hình thức hóa trong bước xác định các kiểm soát cần thiết.
- Điều bắt buộc là dữ liệu không chính xác và không nhất quán phải không được làm hỏng cơ sở dữ liệu, các thâm nhập vô phép vào thông tin cơ sở dữ liệu phải bị ngăn cản.
5.3.2. Chuyển đổi mô hình dữ liệu thành tệp dữ liệu
dữ liệu quan hệ mỗi kiểu thực thể tương ứng một tệp và có thể thêm các thuộc tính tình huống. Phân rã: căn cứ vào sử dụng nếu xảy ra những nhóm thuộc tính hay dùng và ít dùng khi phân rã chúng ra. Những thuộc tính hay dùng cho vào một tệp. Ví dụ: Kiểu thực thể ĐIỂM THI gồm các thuộc tính: SBD, Số phách, Điểm thi. Nhưng để đảm bảo bí mật thường được tách thành hai tệp PHÁCH (Số báo danh, Số phách) và BÀI THI (Số phách, Điểm thi).
Gộp hai hay nhiều kiểu thực thể khi việc sử dụng chúng thường đi liền với nhau. Ví dụ: với hai kiểu thực thể ĐƠN HÀNG và DÒNG ĐƠN HÀNG thường gộp vào một tệp.
Lặp lại các thuộc tính từ các tệp khác nhau. Ví dụ: các thuộc tính để kết nối giữa các tệp.
Lập các tệp chỉ dẫn căn cứ vào đường truy cập và theo các thuộc tính có tần số sử dụng cao. Ví dụ: trong hệ thống tuyển sinh vì yêu cầu xem điểm nhiều nên có thể tạo một tệp có các thuộc tính SBD và Điểm để giúp cho việc tìm kiếm thông tin được nhanh chóng
BÀI 5. THIẾT KẾ CHƯƠNG TRÌNH 5.1. TỔNG QUAN VỀ THIẾT KẾ CHƯƠNG TRÌNH
5.1.1. Mục đích
Xây dựng một kết cấu chương trình đúng đắn, hiệu quả mà với nội dung đó người lập trình có thể viết được chương trình mà không cần hiểu cả về hệ thống. Kết cấu chương trình là tập hợp các module được sắp xếp theo một trật tự quy tắc xác định. Kết cấu chương trình được biểu diễn bởi lược đồ cấu trúc chương trình.
5.1.2. Cách thực hiện
a. Phương pháp
Phương pháp thiết kế có cấu trúc. Phương pháp này cho phép phân tích để biến đổi luồng thông tin thành cấu trúc chương trình. Cách tiếp cận theo hướng từ trên xuống. T rong phương pháp có hai hướng phân tích cá luồng thông tin là phân tích theo biến đổi và phân tích theo giao tác. Hai hướng phân tích có thể tiến hành riêng biệt, nhưng nói chung thường được kết hợp để xây dựng ra một cấu trúc chương trình duy nhất.
Biểu đồ luồng dữ liệu của hệ thống con máy tính và các diễn tả của các module xử lý, thiết kế cơ sở dữ liệu, thiết kế giao diện, thiết kế kiểm soát.
c. Đầu ra
Lược đồ cấu trúc cho ta cấu trúc tổng thể của hệ thống con máy tính dưới dạng module chương trình, diễn tả các module chương trình.
d. Các công việc
- Phân định các module chương trình.
- Xác định mối liên quan giữa các module là lời gọi và các thông tin trao đổi. - Diễn tả các module chương trình.
- Gộp các module thành chương trình. - Thiết kế mẫu chương trình.
5.2. MODULE CHƯƠNG TRÌNH
Lược đồ chương trình còn gọi là lược đồ cấu trúc là một biểu diễn dưới dạng đồ thị của một tập hợp các module cùng với các giao diện giữa các module đó (bao gồm sự chuyển giao điều khiển và chuyển giao dữ liệu).
5.2.1. Module chương trình
Module chương trình là một chương trình con hoặc một nhóm lệnh nằm trong chương. Các đặc trưng cơ bản của một module chương trình.
Thông tin vào, ra: thông tin nhận được từ chương trình gọi nó hoặc thông tin trả lại cho chương trình gọi nó.
Chức năng: là các hàm biến đổi từ thông tin vào đến thông tin ra. Cơ chế: phương thức để thực hiện chức năng trên.
Dữ liệu cục bộ: các chỗ nhớ hay cấu trúc dữ liệu dùng riêng cho nó.
5.2.2. Biểu diễn các module trong lược đồ chương trình
a. Lược đồ chương trình
• Các module: được biểu diễn bởi một hình chữ nhật với tên module ở bên