I. Quy trình phân tích thiết kế chương trình
2. Mô hình IFD của chương trình
Sơ đồ luồng thông tin ( Information Flow Diagram) là một trong hai công cụ thường dùng để phân tích và thiết kế hệ thống thông tin, nó được dùng để mô tả hệ thống thông tin theo cách thức động. Tức là mô tả sự di chuyển của dữ liệu, việc xử lý và lưu trữ trong thế giới vật lý bằng các sơ đồ. Các kí pháp của sơ đồ luồng thông tin như sau:
-Xử lý:
-Kho lưu trữ dữ liệu:
-Dòng thông tin:
-Điều khiển:
Ví dụ:
Sơ đồ luồng thông tin thể hiện hoạt động chấm thi, nhập điểm vào máy tính và in bảng thông báo điểm cho sinh viên cuối mỗi kì học.
Sơ đồ luồng thông tin trong hệ thống chấm, nhập và lên điểm
Các phích vật lý là những mô tả chi tiết hơn bằng lời cho các đối tượng được biểu diễn trên sơ đồ. Rất nhiều thông tin không thể hiện sơ đồ như hình dạng (Format) của các thông tin vào ra, thủ tục xử lý, phương tiện thực hiện xử lý… sẽ được ghi trên các phích vật lý này. Co 3 loại phích : phích luồng thông thin, phích kho dữ liệu, phích xử lý.
Loại thứ hai: Phích kho chứa dữ liệu
Loại thứ 3: Phích xử lý
Mối liên hệ giữa IFD và các phích vật lý của từ điển hệ thống
Sơ đồ luồng dữ liệu dùng để mô tả cũng chính hệ thống thông tin như sơ đồ luồng thông tin nhưng trên góc độ trừu tượng. Trên sơ đồ chỉ bao gồm các luồng dữ liệu, các xử lý, các lưu trữ dữ liệu, nguồn và đích nhưng không hề quan tâm tới nơi, thời điểm và đối tượng chịu trách nhiệm xử lý. Sơ đồ luồng dữ liệu chỉ mô tả đơn thuần hệ thống thông tin làm gì và để làm gì.
Ký pháp dùng cho sơ đồ luồng dữ liệu DFD
Ngôn ngữ sơ đồ luồng dữ liệu DFD sử dụng 4 loại kí pháp cơ bản: thực thể, tiến trình, kho dữ liệu và dòng dữ liệu.
Các ký pháp cơ bản của ngôn ngữ DFD
Ví dụ:
Sơ đồ DFD mức 0 : tính và lên bảng điểm cho sinh viên
Các mức của DFD
Sơ đồ ngữ cảnh ( Context Diagram) thể hiện rất khái quát nội dung chính của hệ thống thông tin. Sơ đồ này không đi vào chi tiết, mà mô tả sao cho một lần nhìn là có thể nhận ra nội dung chính của hệ thống. Để
cho sơ đồ ngữ cảnh sáng sủa, dễ nhìn có thể bỏ qua các kho dữ liệu; bỏ qua các xử lý cập nhật. Sơ đồ khung cảnh còn được gọi là sơ đồ mức 0.
Ví dụ:
Sơ đò khung cảnh hệ thống tính lương của một công ty nước ngoài như sau:
Sơ đồ ngữ cảnh hệ thống tính lương
Phân rã sơ đồ
Để mô tả hệ thống chi tiết hơn người ta dùng kỹ thuật phân rã sơ đồ. Bắt đầu từ sơ đồ khung cảnh, người ta phân ra thành sơ đồ mức 0,mức một, mức hai…
Ví dụ sau là sơ đồ DFD mức 0 của hệ thống tính lương. Sau mức này nếu thấy cần thiết người ta có thể phân rã thành mức 1, mức hai nếu thấy cần thiết.
Sơ đồ DFD mức 0 hệ thống tính lương
Các phích logic
Giống như phích vật lý, phích logic hoàn chỉnh tài liệu cho hệ thống. Có 5 loại phic logic, chúng được dùng mô tả thêm cho luồng dữ liệu, xử lý, kho dữ liệu, tệp dữ liệu và phần tử thông tin.
-Mẫu phíc xử lý logic -Mẫu phíc luồng dữ liệu -Mẫu phíc phần tử thông tin
-Mẫu phíc kho dữ liệu -Mẫu phíc tệp dữ liệu
Ngôn ngữ cấu trúc dùng để mô tả xử lý logic trên phích xử lý
Ngôn ngữ này chứa các động từ như đọc, ghi, sắp xếp, chuyển sang, trộn, cộng, trừ, nhân, chia, hãy thực hiện…Các phép toán số học và logic thường dùng.
Ngôn ngữ cũng dùng các danh từ được dùng để mô tả dữ liệu trong từ điển hệ thống.
Ngôn ngữ cấu trúc không dùng các trạng từ và tính từ.
Ngôn ngữ cấu trúc chỉ dùng các cấu trúc sau để viết các câu: 1.Tiếp theo (Sequence)
2.Nếu …thì…(If…Then)
3.Nếu..thì..Nếu không …Thì (If…Then…Else…End if) 4.Trong khi mà (While…)
5.Cho đến khi (Do..Until)
6.Câu phức hợp bắt đầu kết thúc (Begin…End) 7.Theo các trường hợp (Do…Case)
Ngôn ngữ cấu trúc tiếng Anh cũng có thể dùng khi thiết kế.
Ngôn ngữ này chứa các động từ như: Read, Write, Sort, Move, Merge, Add, Substract, Multily, Division, Do… Các phép toán số học và logic thường dùng.
Ngôn ngữ cũng dùng các danh từ được dùng để mô tả dữ liệu trong từ điển hệ thống.
Ngôn ngữ cấu trúc không dùng các trạng từ và tính từ.
Ví dụ 1 :
Đọc số lượng trong kho
Chọn trường hợp:
Trường hợp 1: Nếu số lượng trong kho lớn hơn hạn mức dự trữ Thực hiện: Không làm gì
Trường hợp 2: Nếu số lượng trong kho nhỏ hơn hạn mức lưu kho
Thực hiện : Tạo một đơn đặt hàng
Trường hợp 3: Hết hàng trong kho
Thực hiện: Đặt hàng khẩn cấp
Hết trường hợp
Một số quy ước quy tắc liên quan đến DFD
1. Mỗi luồng dữ liệu phải có một tên trừ luồng xử lý và kho dữ liệu
2. Dữ liệu chứa trên hai vật mang khác nhau nhưng luôn đi đôi cùng nhau thì có thể tạo ra một luồng duy nhất.
3. Xử lý luôn phải được đánh mã số.
4. Vẽ lại các kho dữ liệu để các luồng dữ liệu không cắt nhau. 5. Tên cho xử lý phải là một động từ.
6. Xử lý buộc phải thực hiện một biến đổi dữ liệu. Luồng vào phải khác với luồng ra từ một xử lý.
Đối với việc phân rã DFD
1. Thông thường một xử lý mà logic xử lý của nó được trình bày bằng ngôn ngữ có cấu trúc chỉ chiếm một trang giấy thì không phân rã tiếp. 2. Cố gắng chỉ để tối đa 7 xử lý trên một trang DFD.
3. Tất cả các xử lý trên một trang DFD phải thuộc cùng một mức phân rã.
4. Luồng vào của một DFD mức cao phải là luồng vào của một DFD mức con nào đó. Luồng ra tới đích của một DFD phải là luồng ra của một DFD mức cao hơn nào đó. Đây gọi là nguyên tắc cân đối của DFD.
5. Xử lý không phân ra tiếp thêm thì được gọi là xử lý nguyên thủy. Mỗi xử lý nguyên thủy phải có một phích logic trong từ điển hệ thống. Sơ đồ luồng thông tin và sơ đồ luồng dữ liệu là hai công cụ thường dùng nhất để phân tích và thiết kế HTTT. Chúng thể hiện hai mức mô hình và hai góc nhìn động và tĩnh về hệ thống.
Những công cụ này được phần lớn các nhà phân tích thiết kế sử dụng bất luận là quy mô dự án lớn hay nhỏ hay kích thước hệ thống lớn hay nhỏ. Ngày nay một số công cụ được tin học hóa, vì vậy có nhiều phần mềm cho phép xây dựng sơ đồ luồng dữ liệu của một hệ thống. Một số phần mềm tinh tế hơn cho tạo ra cả sơ đồ luồng dữ liệu và từ điển hệ thống. Tuy nhiên các công cụ chỉ giúp các nhà phân tích tạo nhanh hơn các sơ đồ hoặc mối liên quan giữa sơ đồ và các yếu tố trong từ điển, chứ nó không thực hiện thay công việc của nhà phân tích và việc phát hiện lỗi trên sơ đồ vẫn thuộc trách nhiệm nhà phân tích.
Đông Tĩnh
Vật lý IFD ( Information Flow Diagram) – Sơ đồ luồn thông tin
SD ( System Dictionary) Từ điển hệ thống
Các phích vật lý. Logic DFD (Data Flow Diagram)
Sơ đồ luồng dữ liệu.
SD (System Dictionary) Từ điển hệ thống
Các phích logic.
Các công cụ phân tích và thiết kế hệ thống thông tin
4. Mô hình hóa và chuẩn hóa dữ liệu4.1. Mô hình hóa dữ liêu là gì ? 4.1. Mô hình hóa dữ liêu là gì ?
Mô hình hóa dữ liệu là quá trình xác định các chi tiết dữ liệu và những mối quan hệ cần được lưu trữ trong một DSDL. Đó cũng là quá trình trao đổi về cách thiết kế CSDL giữa người này với người khác. Mục đích là tạo ra một mô hình dữ liệu trong thế giới thực tại. Những yếu tố cơ bản hợp thành một mô hình dữ liệu là : các thực thể, các thuộc tính của mỗi thực thể, các yếu tố phân biệt của mỗi thực thể và những mối quan hệ giữa các thực thể.
Việc xây dựng mô hình dữ liệu đòi hỏi một sự phối hợp chặt chẽ giữa khách hàng, tức là đại diện của những người dùng, với các nhà thiết kế. Phác họa mô hình dữ liệu là một thử nghiệm, thường phải sửa đi sửa lại nhiều lần. Một mô hình dữ liệu sẽ thay đổi khi người thiết kế hiểu biết nhiều hơn về nhu cầu và lĩnh vực hoạt động của khách hàng. Sản phẩm cuối cùng rất có thể sẽ
khác xa với những phiên bản ban đầu của nhà thiết kế. Tốt nhất là dùng một phần mềm máy tính để vẽ và sửa mô hình dữ liệu được dễ dàng hơn.
4.2. Chất lượng của mô hình dữ liệu
Khi đánh giá chất lượng của một mô hình dữ liệu trước hết ta phải tìm hiểu cặn kẽ bối cảnh của môi trường mà trong đó mô hình được sử dụng, sau đó dựa vào các tính chất của một mô hình dữ liệu hoàn hảo và coi đó là những tiêu chuẩn để đánh giá. Một mô hình dữ liệu hoàn hảo có các tính chất sau đây:
- Tuân thủ mọi quy tắc và quy định về xây dựng mô hình dữ liệu đã được khách hàng chấp nhận.
- Không nhập nhằng dẫn tới hiểu theo nhiều nghĩa khác nhau. (Chẳng hạn, nên dùng cụm từ số hiệu hóa đơn thay cho số hóa đơn để tránh hiểu lầm thành số lượng hóa đơn).
- Các tên thực thể trong một mô hình và các tên thuộc tính của một thực thể không trùng nhau. Các tên đều có nghĩa và gần sát với những tên mà khách hàng thường dùng hàng ngày.
- Mỗi thực thể có ít nhất một yếu tố phân biệt để tránh tình trạng người dùng tra cứu nhầm thực thể này với thực thể khác.
- Tất cả các mối quan hệ đều được ghi nhận bằng các kí hiệu chuẩn xác. Nếu cần thiết thì viết thêm lời mô tả quan hệ để tránh hiểu lầm.
- Tất cả các thực thể và các thuộc tính của thực thể mà khách hàng quan tâm đề được liệt kê trongmô hình.
- Là hình ảnh của dữ liệu với độ trung thực cao (High fidelity image): Những người dùng dữ liệu muốn có hình ảnh dữ liệu với độ trung thực cao, giống như những người say mê âm nhạc muốn có một dàn nhạc với âm thanh có độ trung thực cao nhất không bị bóp méo. Một mô hình dữ liệu là một hình ảnh với độ trung thực cao khi nó mô tả trung thành thế giới thực tại và cung cấp được thông tin chính xác cho người dùng. Độ trung thực của một mô hình dữ liệu phụ thuộc phần lớn vào sự phản ảnh đầy đủ và chính xác các mối quan hệ giữa các thực thể. Chẳng hạn, nếu
một mối quan hệ thực tế là m:m thì nó cũng phải được ghi nhận như vậy trong mô hình.
Một mô hình dữ liệu hoàn hảo sẽ dễ hiểu, dễ dùng đồng thời phản ánh được đầy đủ và chính xác thực tế theo đúng yêu cầu của người dùng.
4.3. Nâng cao chất lượng của mô hình dữ liệu
Để có được một mô hình dữ liệu hoàn hảo thì phải tốn thời gian. Khách hàng phải giải thích vấn đề một cách đầy đủ sao cho người thiết kế có thể hiểu rõ mọi yêu cầu của khách hàng nhằm thiết kế được một mô hình đáp ứng yêu cầu đó. Mô hình hóa dữ liệu giống như một quá trình thử nghiệm và cải biến dần: cán bộ thiết kế dần dần tạo ra một mô hình của CSDL nhờ sự tiếp xúc và trao đổi thường xuyên với khách hàng. Đôi khi mô hình dữ liệu bộc lộ những thiếu sót nghiêm trọng khiến nhà thiết kế phải thay đổi hàng loạt. Sau đây là một số gợi ý để nâng cao chất lượng của mô hình dữ liệu và giảm bớt những sự sửa đổi không đáng phải tiến hành.
a. Mở rộng hay thu hẹp mô hình dữ liệu
Mô hình dữ liệu có thể mở rộng và có thể thu hẹp được. Mô hình dữ liệu sẽ được mở rộng khi ta tăng phạm vi ứng dụng, bổ sung thực thể, thuộc tính và các mối quan hệ để bao trùm cả các trường hợp ngoại lệ. Nói chung, các mô hình dữ liệu thường lớn dần lên, có khi gấp hai ba lần quy mô ban đầu, bởi vì nó cần phản ánh độ phức tạp của thực tế mà người thiết kế không dễ gì nhận thức được đầy đủ ngay từ đầu. Đừng cố ý hạn chế sự tăng trưởng của mô hình dữ liệu mà hãy để cho nó lớn lên đến mức cần thiết. Một mô hình dữ liệu có thể thu hẹp lại khi ta tổng quát hóa các thực thể của nó. Mô hình cũng được thu hẹp khi ta có những cải tiến để biểu diễn các quan hệ một cách đáng tin cậy đúng đắn và ít vụng về hơn. Sau đây là một vài ví dụ về sự cải biến mô hình dữ liệu: Ví dụ 1: Xét trường hợp một công ty có những phòng ban và những tổ đội. Một phòng ban có nhiều tổ đội nhưng mỗi tổ đội chỉ thuộc về một phòng ban. Thoạt đầu, giả sử công ty chỉ cho phép mỗi cán bộ công nhân viên (CBCNV) làm
việc trong một tổ đội duy nhất. Mô hình dữ liệu phản ánh cơ cấu tổ chức theo công việc của công ty được thể hiện như ở hình sau:
Mô hình cơ cấu tổ chức theo công việc
Trong suốt thời kì làm việc cho công ty, một CBCNV có thể thuyên chuyển từ bộ phận này sang bộ phận khác. Thậm chí, công ty có thể thay đổi chủ trương, cho phép một người đồng thời kiêm nhiệm ở nhiều bộ phận. Muốn ghi nhận cả lịch sử, tức là việc làm trong quá khứ, và thể hiện được chủ trương mới của công ty thì cần mở rộng mô hình. Vì một tổ có nhiều CBCNV và một CBCNV có thể làm việc cho nhiều tổ nên ta có quan hệ m:m giữa tổ và CBCNV . Cần có một thực thể giao để biểu diễn mối quan hệ này, ta gọi nó là một thực thể Chuc_vu. Mỗi hiện diện của thực thể, tức là mỗi chức vụ mà CBCNV nào đó đảm nhiệm được xác định duy nhất bởi ngày bắt đầu, kết hợp với mã tổ và mã CBCNV như hình sau:
Mô hình cơ cấu tổ chức theo công việc- Phiên bản 2
Bây giờ ta lại muốn theo dõi các khoản tiền công đã trả cho CBCNV. Một người có nhiều phiếu trả lương (Pay Slip) nhưng mỗi phiếu chỉ thuộc vể một người. Mỗi phiếu trả lương có nhiều dòng ghi tổng lương và các khoản khấu trừ như bảo hiểm y tế, bảo hiểm xã hội… Các dòng của phiếu trả lương tương tự như những dòng của một hóa đơn; mỗi dòng chỉ thuộc về một phiếu. Một lần nữa, mô hình lại được mở rộng như hình sau:
Mô hình cơ cấu tổ chức theo công việc (phiên bản 3)
b. Yếu tố phân biệt – Thực thể độc lập và thực thể phụ thuộc
Nếu không có một yếu tố phân biệt rõ ràng và đơn giản nào thì hãy sáng tạo ra một yếu tố hay nhờ hệ QTCSDL tạo ra. Đơn giản nhất là dùng một mã ngắn gọn làm yếu tố phân biệt. Nếu ta tự tạo ra một yếu tố phân biệt thì cần đảm bảo cho nó có giá trị trùng lặp đối với các cá thể khác nhau.
Đừng chất đầy thông tin vào một yếu tố phân biệt làm cho nó quá tải. Có công ty chất dẻo đã từng đặt ra mã sản phẩm một cách duy nhất mà không còn chỉ ra màu sắc, loại nguyên liệu tạo nên sản phẩm…Màu sắc và loại nguyên liệu đều là những thuộc tính. Nếu mã quá dài thì dễ mắc phải lỗi khi nạp dữ liệu và ít người có thể nhớ cách giải mã để biết được ý nghĩa đầy đủ của nó.
Một yếu tố phân biệt chỉ có một nhiệm vụ là xác định duy nhất từng cá thể. Việc chất thêm gánh nặng cho nó sẽ làm nảy sinh những công việc