Mô hình mối quan hệ thực thể là một loại mô hình cơ sở dữ liệu dựa trên khái niệm về các thực thể trong thế giới thực và mối quan hệ giữa chúng. Chúng ta có thể ánh xạ kịch bản thế giới thực lên mô hình cơ sở dữ liệu ER. Mô hình ER tạo ra một tập hợp các thực thể với các thuộc tính của chúng, một tập hợp các ràng buộc và mối quan hệ giữa chúng.

Mô hình ER được sử dụng tốt nhất cho thiết kế khái niệm cơ sở dữ liệu. Mô hình ER có thể được biểu diễn như sau:

Thực thể – Một thực thể trong Mô hình ER là một thực thể trong thế giới thực, có một số thuộc tính được gọi là thuộc tính . Mỗi thuộc tính được xác định bởi tập giá trị tương ứng của nó, được gọi là miền .

Ví dụ: Hãy xem xét một cơ sở dữ liệu trường học. Ở đây, một sinh viên là một thực thể. Sinh viên có các thuộc tính khác nhau như tên, id, tuổi và lớp, v.v.

Mối quan hệ – Sự liên kết logic giữa các thực thể được gọi là mối quan hệ . Các mối quan hệ được ánh xạ với các thực thể theo nhiều cách khác nhau. Ánh xạ cardinalities xác định số lượng liên kết giữa hai thực thể.

Lập bản đồ các lực lượng:

một đối một
- một đến nhiều
- nhiều thành một
- nhiều nhiều

từ điển dữ liệu

Từ điển dữ liệu là tập hợp tập trung thông tin về dữ liệu. Nó lưu trữ ý nghĩa và nguồn gốc của dữ liệu, mối quan hệ của nó với dữ liệu khác, định dạng dữ liệu để sử dụng, v.v. Từ điển dữ liệu có các định nghĩa chặt chẽ về tất cả các tên để tạo thuận lợi cho người dùng và nhà thiết kế phần mềm.

Từ điển dữ liệu thường được gọi là kho siêu dữ liệu (dữ liệu về dữ liệu). Nó được tạo cùng với mô hình DFD (Sơ đồ luồng dữ liệu) của chương trình phần mềm và dự kiến sẽ được cập nhật bất cứ khi nào DFD được thay đổi hoặc cập nhật.

Yêu cầu của từ điển dữ liệu

Dữ liệu được tham chiếu qua từ điển dữ liệu trong khi thiết kế và triển khai phần mềm. Từ điển dữ liệu loại bỏ bất kỳ khả năng mơ hồ nào. Nó giúp giữ cho công việc của các lập trình viên và nhà thiết kế được đồng bộ hóa trong khi sử dụng cùng một tham chiếu đối tượng ở mọi nơi trong chương trình.

Từ điển dữ liệu cung cấp một cách tài liệu cho hệ thống cơ sở dữ liệu hoàn chỉnh ở một nơi. Việc xác thực DFD được thực hiện bằng cách sử dụng từ điển dữ liệu.

nội dung

Từ điển dữ liệu nên chứa thông tin về những điều sau đây

Dòng dữ liệu
Cấu trúc dữ liệu
Phần tử dữ liệu
Kho dữ liệu
Xử lí dữ liệu

Luồng dữ liệu được mô tả bằng DFD như đã nghiên cứu trước đó và được biểu diễn dưới dạng đại số như đã mô tả.

=	Gồm
{}	sự lặp lại
()	Không bắt buộc
+	Và
[ / ]	Hoặc

Ví dụ

Địa chỉ = Số nhà + (Đường phố / Khu vực) + Thành phố + Tiểu bang

ID khóa học = Mã số khóa học + Tên khóa học + Cấp độ khóa học + Điểm khóa học

Phần tử dữ liệu

Các phần tử dữ liệu bao gồm Tên và các mô tả về Dữ liệu và Mục kiểm soát, kho lưu trữ dữ liệu Nội bộ hoặc Bên ngoài, v.v. với các chi tiết sau:

Tên chính
Tên phụ (Bí danh)
Trường hợp sử dụng (Làm thế nào và ở đâu để sử dụng)
Mô tả nội dung (Ký hiệu, v.v.)
Thông tin bổ sung (giá trị đặt trước, ràng buộc, v.v.)

Kho dữ liệu

Nó lưu trữ thông tin từ nơi dữ liệu nhập vào hệ thống và tồn tại bên ngoài hệ thống. Kho dữ liệu có thể bao gồm –

Các tập tin
- Nội bộ của phần mềm.
- Bên ngoài phần mềm nhưng trên cùng một máy.
- Bên ngoài phần mềm và hệ thống, nằm trên máy khác.
Những cái bàn
- Quy ước đặt tên
- Thuộc tính lập chỉ mục

Xử lí dữ liệu

Có hai loại Xử lý dữ liệu:

Hợp lý: Khi người dùng nhìn thấy nó

Vật lý: Khi phần mềm nhìn thấy nó

Chiến lược thiết kế phần mềm

Thiết kế phần mềm là một quá trình khái niệm hóa các yêu cầu phần mềm thành việc triển khai phần mềm. Thiết kế phần mềm lấy các yêu cầu của người dùng làm thách thức và cố gắng tìm ra giải pháp tối ưu. Trong khi phần mềm đang được lên ý tưởng, một kế hoạch được vạch ra để tìm ra thiết kế tốt nhất có thể để thực hiện giải pháp đã định.

Có nhiều biến thể của thiết kế phần mềm. Hãy để chúng tôi nghiên cứu chúng một cách ngắn gọn:

Thiết kế có cấu trúc

Thiết kế có cấu trúc là một khái niệm hóa vấn đề thành một số yếu tố được tổ chức tốt của giải pháp. Về cơ bản, nó liên quan đến thiết kế giải pháp. Lợi ích của thiết kế có cấu trúc là nó giúp hiểu rõ hơn về cách giải quyết vấn đề. Thiết kế có cấu trúc cũng giúp người thiết kế tập trung vào vấn đề một cách chính xác hơn.

Thiết kế có cấu trúc chủ yếu dựa trên chiến lược ‘chia để trị’ trong đó một vấn đề được chia thành nhiều vấn đề nhỏ và mỗi vấn đề nhỏ được giải quyết riêng lẻ cho đến khi toàn bộ vấn đề được giải quyết.

Các phần nhỏ của vấn đề được giải quyết bằng các mô-đun giải pháp. Thiết kế có cấu trúc nhấn mạnh rằng các mô-đun này được tổ chức tốt để đạt được giải pháp chính xác.

Các mô-đun này được sắp xếp theo thứ bậc. Họ giao tiếp với nhau. Một thiết kế có cấu trúc tốt luôn tuân theo một số quy tắc để giao tiếp giữa nhiều mô-đun, cụ thể là –

Sự gắn kết – nhóm tất cả các yếu tố liên quan đến chức năng.

Khớp nối – giao tiếp giữa các mô-đun khác nhau.

Một thiết kế có cấu trúc tốt có sự gắn kết cao và sắp xếp khớp nối thấp.

Thiết kế hướng chức năng

Trong thiết kế hướng chức năng, hệ thống bao gồm nhiều hệ thống con nhỏ hơn được gọi là các chức năng. Các chức năng này có khả năng thực hiện nhiệm vụ quan trọng trong hệ thống. Hệ thống được coi là quan điểm hàng đầu của tất cả các chức năng.

Thiết kế hướng chức năng kế thừa một số thuộc tính của thiết kế có cấu trúc trong đó phương pháp phân chia và chinh phục được sử dụng.

Cơ chế thiết kế này chia toàn bộ hệ thống thành các chức năng nhỏ hơn, cung cấp phương tiện trừu tượng hóa bằng cách che giấu thông tin và hoạt động của chúng.. Các mô-đun chức năng này có thể chia sẻ thông tin với nhau bằng cách truyền thông tin và sử dụng thông tin có sẵn trên toàn cầu.

Một đặc điểm khác của các hàm là khi một chương trình gọi một hàm, hàm đó sẽ thay đổi trạng thái của chương trình, điều này đôi khi không được các mô-đun khác chấp nhận. Thiết kế hướng chức năng hoạt động tốt khi trạng thái hệ thống không quan trọng và chương trình/chức năng hoạt động trên đầu vào hơn là trên trạng thái.

Quá trình thiết kế

Toàn bộ hệ thống được xem như cách dữ liệu chảy trong hệ thống bằng sơ đồ luồng dữ liệu.
DFD mô tả cách các chức năng thay đổi dữ liệu và trạng thái của toàn bộ hệ thống.
Toàn bộ hệ thống được chia nhỏ một cách hợp lý thành các đơn vị nhỏ hơn được gọi là các chức năng trên cơ sở hoạt động của chúng trong hệ thống.
Mỗi chức năng sau đó được mô tả ở mức độ lớn.

Thiết kế hướng đối tượng

Thiết kế hướng đối tượng hoạt động xung quanh các thực thể và đặc điểm của chúng thay vì các chức năng liên quan đến hệ thống phần mềm. Chiến lược thiết kế này tập trung vào các thực thể và đặc điểm của nó. Toàn bộ khái niệm về giải pháp phần mềm xoay quanh các thực thể tham gia.

Chúng ta hãy xem các khái niệm quan trọng của Thiết kế hướng đối tượng:

Đối tượng – Tất cả các thực thể liên quan đến thiết kế giải pháp được gọi là đối tượng. Ví dụ: người, ngân hàng, công ty và khách hàng được coi là đối tượng. Mỗi thực thể có một số thuộc tính được liên kết với nó và có một số phương thức để thực hiện trên các thuộc tính.
Các lớp – Một lớp là một mô tả tổng quát của một đối tượng. Một đối tượng là một thể hiện của một lớp. Lớp định nghĩa tất cả các thuộc tính mà một đối tượng có thể có và các phương thức xác định chức năng của đối tượng.

Trong thiết kế giải pháp, các thuộc tính được lưu trữ dưới dạng các biến và các chức năng được xác định bằng các phương thức hoặc thủ tục.

Đóng gói – Trong OOD, các thuộc tính (biến dữ liệu) và phương thức (thao tác trên dữ liệu) được gộp lại với nhau được gọi là đóng gói. Đóng gói không chỉ kết hợp thông tin quan trọng của một đối tượng với nhau mà còn hạn chế quyền truy cập dữ liệu và phương thức từ thế giới bên ngoài. Điều này được gọi là che giấu thông tin.
Kế thừa – OOD cho phép các lớp tương tự xếp chồng lên nhau theo cách phân cấp trong đó các lớp thấp hơn hoặc lớp con có thể nhập, triển khai và sử dụng lại các biến và phương thức được phép từ các lớp siêu trực tiếp của chúng. Tài sản này của OOD được gọi là thừa kế. Điều này làm cho việc định nghĩa lớp cụ thể và tạo các lớp tổng quát từ các lớp cụ thể trở nên dễ dàng hơn.
Tính đa hình – Các ngôn ngữ OOD cung cấp một cơ chế trong đó các phương thức thực hiện các tác vụ tương tự nhưng khác nhau về đối số, có thể được gán cùng tên. Điều này được gọi là tính đa hình, cho phép một giao diện duy nhất thực hiện các tác vụ cho các loại khác nhau. Tùy thuộc vào cách chức năng được gọi, phần mã tương ứng sẽ được thực thi.

Quá trình thiết kế

Quy trình thiết kế phần mềm có thể được coi là một loạt các bước được xác định rõ. Mặc dù nó thay đổi tùy theo cách tiếp cận thiết kế (hướng chức năng hoặc hướng đối tượng, nhưng nó có thể bao gồm các bước sau:

Một thiết kế giải pháp được tạo ra từ yêu cầu hoặc hệ thống được sử dụng trước đó và/hoặc sơ đồ trình tự hệ thống.
Các đối tượng được xác định và nhóm thành các lớp dựa trên sự giống nhau về đặc điểm thuộc tính.
Hệ thống phân cấp lớp và mối quan hệ giữa chúng được xác định.
Khung ứng dụng được xác định.

Phương pháp tiếp cận thiết kế phần mềm

Dưới đây là hai cách tiếp cận chung cho thiết kế phần mềm:

Thiết kế từ trên xuống

Chúng tôi biết rằng một hệ thống bao gồm nhiều hơn một hệ thống con và nó chứa một số thành phần. Hơn nữa, các hệ thống con và thành phần này có thể có các thành phần và hệ thống con của chúng và tạo ra cấu trúc phân cấp trong hệ thống.

Thiết kế từ trên xuống lấy toàn bộ hệ thống phần mềm như một thực thể và sau đó phân tách nó để đạt được nhiều hơn một hệ thống con hoặc thành phần dựa trên một số đặc điểm. Mỗi hệ thống con hoặc thành phần sau đó được coi là một hệ thống và được phân tách hơn nữa. Quá trình này tiếp tục chạy cho đến khi đạt được mức hệ thống thấp nhất trong hệ thống phân cấp từ trên xuống.

Thiết kế từ trên xuống bắt đầu với một mô hình tổng quát của hệ thống và tiếp tục xác định phần cụ thể hơn của nó. Khi tất cả các thành phần được cấu thành, toàn bộ hệ thống sẽ tồn tại.

Thiết kế từ trên xuống phù hợp hơn khi giải pháp phần mềm cần được thiết kế từ đầu và các chi tiết cụ thể chưa được biết.

Thiết kế từ dưới lên

Mô hình thiết kế từ dưới lên bắt đầu với hầu hết các thành phần cụ thể và cơ bản. Nó tiếp tục với việc kết hợp các thành phần cấp độ cao hơn bằng cách sử dụng các thành phần cấp độ cơ bản hoặc thấp hơn. Nó tiếp tục tạo ra các thành phần cấp cao hơn cho đến khi hệ thống mong muốn không được phát triển thành một thành phần duy nhất. Với mỗi cấp độ cao hơn, số lượng trừu tượng được tăng lên.

Chiến lược từ dưới lên phù hợp hơn khi một hệ thống cần được tạo ra từ một số hệ thống hiện có, trong đó các nguyên mẫu cơ bản có thể được sử dụng trong hệ thống mới hơn.

Cả hai cách tiếp cận từ trên xuống và từ dưới lên đều không thực tế riêng lẻ. Thay vào đó, một sự kết hợp tốt của cả hai được sử dụng.