Case-công nghệ thiết kế hệ thống thông tin. CASE công cụ để thiết kế hệ thống thông tin

Các cách tiếp cận thiết kế vi mạch.

Có hai cách tiếp cận chính để thiết kế hệ thống thông tin:

· cấu trúc

· tiến trình .

Phương pháp tiếp cận cấu trúc dựa trên việc sử dụng cơ cấu tổ chức của công ty, khi việc thiết kế hệ thống được thực hiện bởi các bộ phận cơ cấu. Các công nghệ hoạt động trong trường hợp này được mô tả thông qua các công nghệ hoạt động của các bộ phận cấu trúc và sự tương tác của chúng.

Nếu một công ty là một cấu trúc phức tạp như công ty mẹ, hoặc doanh nghiệp mạng, thì cũng cần phải có một mô hình tương tác của tất cả các yếu tố cấu thành, mô hình này không chỉ phản ánh các khía cạnh công nghệ mà còn cả các khía cạnh tài chính và pháp lý.

Những bất lợi chính của cách tiếp cận cơ cấu là liên kết với cơ cấu tổ chức, thay đổi rất nhanh, do đó, thường phải thực hiện các thay đổi đối với Dự án hệ thống của hệ thống thông tin. Và việc thay đổi IS đã hoàn thành, theo quy luật, là một quá trình khá tốn công, kéo dài và tẻ nhạt.

Phương pháp tiếp cận quy trình không tập trung vào cơ cấu tổ chức mà tập trung vào các quy trình kinh doanh, tức là Ví dụ, một công ty tham gia vào việc cung cấp thiết bị, cung cấp linh kiện và phụ tùng, bảo trì thiết bị, v.v. Đây sẽ là các quy trình kinh doanh của nó, phải được phân tích ở giai đoạn đầu tiên của thiết kế IS.

Phương pháp tiếp cận quy trình hứa hẹn hơn vì các quy trình kinh doanh, ngược lại với cơ cấu tổ chức, thay đổi ít thường xuyên hơn. Hơn nữa, các quy trình nghiệp vụ chính tại doanh nghiệp rất ít, thường không quá mười.

Trong điều kiện hiện đại, tính phức tạp của việc tạo ra các hệ thống thông tin là rất cao. Do đó, trong thiết kế vi mạch, công nghệ CASE ngày nay đã được sử dụng rộng rãi.

Công nghệ CASE Là một gói phần mềm tự động hóa toàn bộ quy trình công nghệ phân tích, thiết kế, phát triển và bảo trì phần mềm phức tạp.

Các công cụ CASE hiện đại bao gồm nhiều lĩnh vực hỗ trợ cho nhiều công nghệ thiết kế vi mạch: từ các công cụ phân tích và tài liệu đơn giản đến các công cụ tự động hóa quy mô đầy đủ bao gồm toàn bộ vòng đời phần mềm.

Các giai đoạn phát triển IS tốn nhiều thời gian nhất là giai đoạn phân tích và thiết kế, trong đó các công cụ CASE đảm bảo chất lượng cao của các giải pháp kỹ thuật và chuẩn bị tài liệu dự án. Đồng thời, các công cụ đồ họa để mô hình hóa lĩnh vực chủ đề đóng một vai trò quan trọng, cho phép các nhà phát triển nghiên cứu trực quan IS hiện có, xây dựng lại nó phù hợp với các mục tiêu và các ràng buộc hiện có.

Các công cụ CASE tích hợp có những điều sau đây tính năng đặc trưng:

· Đảm bảo quản lý quá trình phát triển IS;

· Sử dụng một kho lưu trữ siêu dữ liệu (kho lưu trữ) của dự án được tổ chức đặc biệt.

Các công cụ CASE tích hợp chứa các thành phần sau:

· Các công cụ thiết kế và phân tích đồ họa được sử dụng để mô tả và lập tài liệu IS;

· Các công cụ phát triển ứng dụng, bao gồm ngôn ngữ lập trình và trình tạo mã;

· Một kho lưu trữ cung cấp lưu trữ các phiên bản của dự án đang được phát triển và các thành phần riêng lẻ của nó, đồng bộ hóa luồng thông tin từ các nhà phát triển khác nhau trong quá trình phát triển nhóm, kiểm soát siêu dữ liệu để hoàn thiện và nhất quán;

· Các công cụ để quản lý quá trình phát triển IS;

· Phương tiện tài liệu;

· Công cụ kiểm tra;

· Các công cụ tái cấu trúc cung cấp phân tích mã chương trình và lược đồ cơ sở dữ liệu và hình thành các mô hình và đặc điểm thiết kế khác nhau trên cơ sở chúng.

Tất cả các công cụ CASE hiện đại được chia thành hai nhóm. Nhóm đầu tiên tổ chức các phương tiện được xây dựng trong hệ thống thực hiện, trong đó tất cả các quyết định thiết kế và triển khai đều gắn liền với hệ quản trị cơ sở dữ liệu đã chọn. Nhóm thứ hai tổ chức các phương tiện độc lập với hệ thống thực hiện, trong đó tất cả các quyết định thiết kế đều tập trung vào việc thống nhất các giai đoạn ban đầu của vòng đời và phương tiện tài liệu của chúng. Những công cụ này cung cấp sự linh hoạt tuyệt vời trong việc lựa chọn các công cụ thực hiện.

Chính phẩm giá Công nghệ CASE - hỗ trợ cho công việc tập thể trong một dự án do khả năng làm việc trong một mạng cục bộ, xuất và nhập các đoạn dự án riêng lẻ giữa các nhà phát triển, quản lý dự án có tổ chức.

Như giai đoạn tạo ra các sản phẩm phần mềm cho hệ thống thông tin, có thể phân biệt những điều sau:

1. Môi trường hoạt động được xác định. Ở giai đoạn này, một tập hợp các quy trình của vòng đời IP được xác định, phạm vi của IP được xác định, kích thước của các ứng dụng được hỗ trợ được xác định, tức là các giới hạn được đặt trên các giá trị như số dòng mã chương trình, kích thước của cơ sở dữ liệu, số lượng mục dữ liệu, số lượng đối tượng điều khiển, v.v.

2. Việc xây dựng các sơ đồ và phân tích đồ họa được thực hiện. Ở giai đoạn này, các sơ đồ được xây dựng để thiết lập kết nối với các nguồn thông tin và người tiêu dùng, xác định các quá trình chuyển đổi dữ liệu và nơi chúng được lưu trữ.

3. Đặc điểm kỹ thuật và yêu cầu đối với hệ thống được xác định (kiểu giao diện, kiểu dữ liệu, cấu trúc hệ thống, chất lượng, hiệu suất, phương tiện kỹ thuật, tổng chi phí, v.v.).

4. Đang tiến hành lập mô hình dữ liệu; thông tin được nhập mô tả các phần tử dữ liệu của hệ thống và các mối quan hệ của chúng.

5. Các quy trình đang được mô hình hóa, tức là thông tin được giới thiệu mô tả các quá trình của hệ thống và các mối quan hệ của chúng.

6. Đang tiến hành thiết kế kiến ​​trúc của phần mềm tương lai.

7. Đang tiến hành lập mô hình mô phỏng; mô hình hóa các khía cạnh khác nhau của hiệu suất hệ thống dựa trên thông số kỹ thuật yêu cầu và / hoặc thông số kỹ thuật thiết kế.

8. Tạo mẫu, tức là. một phiên bản sơ bộ của toàn bộ hệ thống hoặc các thành phần riêng lẻ của nó được tạo ra.

9. Truy tìm, phân tích hoạt động của hệ thống được thực hiện từ việc xác định các yêu cầu cho đến kết quả cuối cùng.

10. Mã chương trình được tạo, biên dịch và gỡ lỗi.

11. Kiểm thử phần mềm đã nhận. Phân tích và đánh giá kết quả thu được.

Để tự động hóa việc thiết kế và phát triển hệ thống thông tin trong những năm 70 và 80, một phương pháp cấu trúc đã được sử dụng rộng rãi, có nghĩa là sử dụng các phương pháp chính thức để mô tả hệ thống đang được phát triển và các quyết định kỹ thuật được đưa ra. Đồng thời, các công cụ đồ họa đã được sử dụng để mô tả các mô hình khác nhau của hệ thống thông tin với sự trợ giúp của các sơ đồ và biểu đồ. Đây là một trong những lý do giải thích cho sự xuất hiện của phần mềm và công cụ công nghệ, được gọi là CASE-tools và triển khai chúng CASE-công nghệ để tạo và duy trì hệ thống thông tin.

Thuật ngữ CASE (Phần mềm hỗ trợ máy tính / Kỹ thuật hệ thống) được sử dụng theo nghĩa rất rộng. Ý nghĩa ban đầu của thuật ngữ CASE chỉ giới hạn trong các vấn đề về tự động hóa phát triển phần mềm. Hiện tại, thuật ngữ này đã nhận được một nghĩa rộng hơn, nghĩa là tự động hóa phát triển hệ thống thông tin.

TRƯỜNG HỢP- quỹ là các công cụ phần mềm hỗ trợ quá trình tạo và / hoặc duy trì hệ thống thông tin, chẳng hạn như: phân tích và hình thành các yêu cầu, thiết kế cơ sở dữ liệu và ứng dụng, tạo mã, kiểm tra, đảm bảo chất lượng, cấu hình và quản lý dự án.

TRƯỜNG HỢP- hệ thống có thể được định nghĩa là một tập hợp các công cụ CASE có mục đích chức năng cụ thể và được thực thi trong một sản phẩm phần mềm duy nhất.

TRƯỜNG HỢP- Công nghệ là một tập hợp các phương pháp luận để phân tích, thiết kế, phát triển và bảo trì các hệ thống phức tạp và được hỗ trợ bởi một tập hợp các công cụ tự động hóa được kết nối với nhau.

TRƯỜNG HỢP- ngành công nghiệp hợp nhất hàng trăm công ty và công ty thuộc nhiều lĩnh vực hoạt động khác nhau. Hầu hết các dự án phần mềm lớn của nước ngoài đều được thực hiện bằng CASE-tools và tổng số gói phân phối vượt quá 500 đầu sách.

mục tiêu chính TRƯỜNG HỢP -hệ thống và phương tiện là tách thiết kế của phần mềm khỏi mã hóa và các giai đoạn phát triển tiếp theo của nó (thử nghiệm, tài liệu, v.v.), và cũng để tự động hóa toàn bộ quá trình tạo hệ thống phần mềm, hoặc kỹ thuật(từ tiếng Anh kỹ thuật - phát triển).

Các công cụ CASE hiện đại hỗ trợ nhiều loại công nghệ thiết kế hệ thống thông tin: từ các công cụ phân tích và tài liệu đơn giản đến các công cụ tự động hóa quy mô đầy đủ trong toàn bộ vòng đời của phần mềm.

Các giai đoạn phát triển IS tốn nhiều thời gian nhất là giai đoạn phân tích và thiết kế, trong đó các công cụ CASE đảm bảo chất lượng của các quyết định kỹ thuật được đưa ra và việc chuẩn bị tài liệu dự án. Trong trường hợp này, các phương pháp trình bày thông tin bằng hình ảnh đóng một vai trò quan trọng. Điều này liên quan đến việc xây dựng các sơ đồ cấu trúc hoặc các sơ đồ khác trong thời gian thực, sử dụng bảng màu đa dạng và kiểm tra các quy tắc cú pháp từ đầu đến cuối. Các công cụ đồ họa để mô hình hóa lĩnh vực chủ đề cho phép các nhà phát triển nghiên cứu một cách trực quan hệ thống thông tin hiện có, xây dựng lại nó phù hợp với các mục tiêu và các ràng buộc hiện có.

CASE-công cụ tạo thành nền tảng của bất kỳ dự án IS nào. Phương pháp luận được thực hiện thông qua các công nghệ cụ thể và các tiêu chuẩn, phương pháp luận và công cụ hỗ trợ của chúng để đảm bảo việc thực hiện các quá trình vòng đời của hệ thống thông tin.

Các tính năng đặc trưng của công cụ CASE:

- Ngôn ngữ đồ họa thống nhất... Công nghệ CASE cung cấp cho tất cả những người tham gia dự án, bao gồm cả khách hàng, một ngôn ngữ đồ họa chặt chẽ, rõ ràng và trực quan cho phép bạn có được các thành phần hiển thị với cấu trúc đơn giản và rõ ràng. Đồng thời, các chương trình được thể hiện bằng biểu đồ hai chiều (dễ sử dụng hơn so với mô tả nhiều trang), cho phép khách hàng tham gia vào quá trình phát triển và các nhà phát triển giao tiếp với các chuyên gia về chủ đề, để tách biệt các hoạt động của các nhà phân tích, thiết kế và lập trình hệ thống, giúp họ dễ dàng bảo vệ dự án trước ban quản lý, cũng như dễ dàng bảo trì và thực hiện các thay đổi đối với hệ thống.

- Cơ sở dữ liệu dự án hợp nhất... Cơ sở của công nghệ CASE là việc sử dụng cơ sở dữ liệu dự án (kho lưu trữ) để lưu trữ tất cả thông tin về dự án, có thể được chia sẻ bởi các nhà phát triển phù hợp với quyền truy cập của họ. Nội dung của kho lưu trữ không chỉ bao gồm các đối tượng thông tin thuộc nhiều loại khác nhau, mà còn bao gồm các mối quan hệ giữa các thành phần của chúng, cũng như các quy tắc cho việc áp dụng hoặc xử lý các thành phần này. Kho lưu trữ có thể lưu trữ các đối tượng thuộc nhiều loại khác nhau: sơ đồ cấu trúc, định nghĩa màn hình và menu, dự án báo cáo, mô tả dữ liệu và logic xử lý của chúng, cũng như mô hình dữ liệu, tổ chức và xử lý, mã nguồn, mục dữ liệu, v.v.

- tích hợp các quỹ... Trên cơ sở kho lưu trữ, việc tích hợp các công cụ CASE và phân tách thông tin hệ thống giữa các nhà phát triển được thực hiện. Đồng thời, các khả năng của kho lưu trữ cung cấp một số cấp độ tích hợp: giao diện người dùng chung cho tất cả các công cụ, truyền dữ liệu giữa các công cụ, tích hợp các giai đoạn phát triển thông qua một hệ thống duy nhất để đại diện cho các giai đoạn vòng đời, chuyển dữ liệu và các công cụ giữa các nền tảng.

- Hỗ trợ phát triển nhóm và quản lý dự án... Công nghệ CASE hỗ trợ phát triển dự án nhóm, cung cấp khả năng làm việc trong mạng, xuất-nhập bất kỳ phân đoạn dự án nào để phát triển và / hoặc sửa đổi chúng, cũng như lập kế hoạch, kiểm soát, lãnh đạo và tương tác, nghĩa là các chức năng cần thiết trong quá trình phát triển và bảo trì các dự án. Các tính năng này cũng được triển khai trên cơ sở kho lưu trữ. Đặc biệt, kiểm soát bảo mật (hạn chế và đặc quyền truy cập), kiểm soát phiên bản và thay đổi, v.v. có thể được thực hiện thông qua kho lưu trữ.

- Bố trí... Công nghệ CASE giúp bạn có thể nhanh chóng xây dựng các bố cục (nguyên mẫu) của một hệ thống trong tương lai, cho phép khách hàng ở giai đoạn đầu của quá trình phát triển đánh giá xem nó phù hợp với anh ta đến mức nào và mức độ chấp nhận của nó đối với người dùng trong tương lai.

- Tạo tài liệu... Tất cả tài liệu dự án được tạo tự động trên cơ sở kho lưu trữ (theo quy định, phù hợp với các yêu cầu của tiêu chuẩn áp dụng). Lợi thế chắc chắn của công nghệ CASE là tài liệu luôn tương ứng với tình trạng hiện tại của công việc, vì bất kỳ thay đổi nào trong dự án đều được tự động phản ánh trong kho lưu trữ (được biết rằng với các cách tiếp cận truyền thống để phát triển phần mềm, tài liệu là muộn nhất, và một số sửa đổi hoàn toàn không được tìm thấy trong phản ánh của cô ấy).

- Xác minh dự án... Công nghệ CASE cung cấp khả năng xác minh và kiểm soát tự động dự án để đảm bảo tính hoàn chỉnh và nhất quán ở giai đoạn đầu của quá trình phát triển, điều này ảnh hưởng đến sự thành công của quá trình phát triển nói chung.

- Tự động tạo mã chương trình... Việc tạo mã chương trình được thực hiện trên cơ sở kho lưu trữ và cho phép tự động xây dựng tới 85–90% văn bản bằng các ngôn ngữ cấp cao.

- Bảo trì và tái cấu trúc... Việc bảo trì hệ thống trong khuôn khổ của công nghệ CASE được đặc trưng bởi việc duy trì dự án chứ không phải mã chương trình. Các công cụ tái cấu trúc cho phép bạn tạo một mô hình của hệ thống từ các mã của nó và tích hợp các mô hình kết quả vào dự án, tự động cập nhật tài liệu khi thay đổi mã, tự động thay đổi thông số kỹ thuật khi chỉnh sửa mã, v.v.

Việc phát triển các chương trình bắt đầu với một số phiên bản sơ bộ của hệ thống. Một nguyên mẫu được phát triển đặc biệt hoặc một hệ thống lỗi thời có thể hoạt động như một tùy chọn như vậy. Trong trường hợp thứ hai, để khôi phục kiến ​​thức về hệ thống phần mềm cho mục đích sử dụng tiếp theo của chúng, việc phát triển lại được sử dụng - tái cấu trúc.

Việc phát triển lại được rút gọn thành việc xây dựng mô hình ban đầu của một hệ thống phần mềm bằng cách kiểm tra các mã phần mềm của nó. Có một mô hình, bạn có thể cải thiện nó, và sau đó quay lại phát triển. Một trong những nguyên tắc nổi tiếng nhất của loại hình này là nguyên tắc Kỹ thuật chuyến đi vòng quanh (RTE).

Các hệ thống CASE hiện đại cung cấp cả tính năng chính và tái phát triển, giúp tăng tốc đáng kể sự phát triển của các ứng dụng và cải thiện chất lượng của chúng.

Hiện tại, trong số các yêu cầu khác đối với công cụ CASE, các yêu cầu sau được áp dụng:

Khả năng xác định mô hình chính của vấn đề được áp dụng (mô hình kinh doanh, thường là hướng đối tượng) và các quy tắc hành vi của nó (các quy tắc nghiệp vụ);

Hỗ trợ quá trình thiết kế bằng cách sử dụng các thư viện được trang bị các công cụ để lưu trữ, tìm kiếm và lựa chọn các yếu tố thiết kế (đối tượng và quy tắc);

Tính sẵn có của các công cụ để tạo giao diện người dùng và duy trì các giao diện lập trình chung (hỗ trợ các tiêu chuẩn OLE, OpenDoc, quyền truy cập vào thư viện HTML / Java, v.v.);

Khả năng tạo các ứng dụng máy khách-máy chủ phân tán khác nhau.

Các xu hướng phát triển của công nghệ thông tin hiện đại dẫn đến sự gia tăng không ngừng về mức độ phức tạp của các hệ thống thông tin (IS) được tạo ra trong các lĩnh vực khác nhau của nền kinh tế. Theo quy luật, các dự án IP lớn hiện đại được đặc trưng bởi các đặc điểm sau:

sự phức tạp của mô tả (một số lượng đủ lớn các chức năng, quy trình, phần tử dữ liệu và các mối quan hệ phức tạp giữa chúng), yêu cầu mô hình hóa và phân tích dữ liệu và quy trình một cách cẩn thận;

sự hiện diện của một tập hợp các thành phần tương tác chặt chẽ (hệ thống con) có các nhiệm vụ cục bộ và mục tiêu hoạt động của riêng chúng (ví dụ: các ứng dụng truyền thống liên quan đến xử lý giao dịch và giải quyết các nhiệm vụ thông thường và các ứng dụng xử lý phân tích (hỗ trợ quyết định) bằng cách sử dụng các truy vấn đặc biệt dữ liệu lớn);

thiếu các chất tương tự trực tiếp, hạn chế khả năng sử dụng bất kỳ giải pháp thiết kế điển hình và hệ thống ứng dụng nào;

nhu cầu tích hợp các ứng dụng hiện có và mới được phát triển;

hoạt động trong một môi trường không đồng nhất trên nhiều nền tảng phần cứng;

sự mất đoàn kết và không đồng nhất của các nhóm nhà phát triển nhất định về trình độ kỹ năng và truyền thống sử dụng một số công cụ nhất định;

Khoảng thời gian đáng kể của dự án, một mặt, do khả năng hạn chế của nhóm phát triển, mặt khác, do quy mô của tổ chức khách hàng và mức độ sẵn sàng khác nhau của các bộ phận riêng lẻ để triển khai IS .

Để thực hiện thành công dự án, đối tượng thiết kế (IS) trước hết phải được mô tả đầy đủ, phải xây dựng các mô hình chức năng và thông tin hoàn chỉnh và nhất quán của IS. Kinh nghiệm thiết kế vi mạch được tích lũy cho đến nay cho thấy đây là công việc phức tạp về mặt logic, tốn nhiều công sức và thời gian, đòi hỏi trình độ chuyên môn cao của các chuyên gia tham gia. Tuy nhiên, cho đến gần đây, thiết kế vi mạch chủ yếu được thực hiện ở mức độ trực quan, sử dụng các phương pháp phi chính thức dựa trên nghệ thuật, kinh nghiệm thực tế, đánh giá của chuyên gia và các thử nghiệm thực nghiệm tốn kém về chất lượng hoạt động của vi mạch. Ngoài ra, trong quá trình tạo và vận hành IS, nhu cầu thông tin của người dùng có thể thay đổi hoặc được tinh chỉnh, điều này càng làm phức tạp thêm việc phát triển và bảo trì các hệ thống đó.

Trong những năm 70 và 80, trong quá trình phát triển của IS, một phương pháp cấu trúc đã được sử dụng rộng rãi, cung cấp cho các nhà phát triển các phương pháp chính thức hóa nghiêm ngặt để mô tả IS và các quyết định kỹ thuật được đưa ra. Nó dựa trên một kỹ thuật đồ họa trực quan: các lược đồ và sơ đồ được sử dụng để mô tả các loại mô hình IP khác nhau. Sự rõ ràng và chặt chẽ của các công cụ phân tích cấu trúc cho phép các nhà phát triển và người dùng tương lai của hệ thống ngay từ đầu tham gia một cách không chính thức vào việc tạo ra nó, thảo luận và củng cố sự hiểu biết về các giải pháp kỹ thuật chính. Tuy nhiên, việc sử dụng rộng rãi phương pháp luận này và tuân thủ các khuyến nghị của nó trong việc phát triển các IS cụ thể là khá hiếm, vì với việc phát triển thủ công (thủ công) thì điều đó gần như là không thể. Thật vậy, rất khó để phát triển theo cách thủ công và biểu diễn bằng đồ thị các thông số kỹ thuật nghiêm ngặt của hệ thống chính thức, kiểm tra tính hoàn chỉnh và nhất quán của chúng, và hơn thế nữa là thay đổi chúng. Tuy nhiên, nếu có thể tạo ra một hệ thống tài liệu dự án chặt chẽ, thì việc sửa đổi nó khi có những thay đổi nghiêm trọng trên thực tế là không thể. Phát triển thủ công thường dẫn đến các vấn đề sau:

đặc tả yêu cầu không đầy đủ;

không có khả năng phát hiện sai sót trong các quyết định thiết kế;

chất lượng tài liệu kém, giảm hiệu suất;

chu kỳ dài và kết quả kiểm tra kém.

Mặt khác, các nhà thiết kế vi mạch trong lịch sử là những người cuối cùng sử dụng công nghệ máy tính để cải thiện chất lượng, độ tin cậy và năng suất trong công việc của chính họ (hiện tượng “thợ đóng giày không đi ủng”).

Các yếu tố được liệt kê đã góp phần vào sự xuất hiện của phần mềm và công cụ công nghệ thuộc một lớp đặc biệt - CASE-các công cụ thực hiện CASE-công nghệ để tạo và duy trì IS. Thuật ngữ CASE (Kỹ thuật phần mềm hỗ trợ máy tính) hiện đang được sử dụng theo nghĩa rất rộng. Ý nghĩa ban đầu của thuật ngữ CASE, vốn chỉ giới hạn trong các vấn đề tự động hóa phát triển phần mềm (phần mềm) duy nhất, nay đã mang một ý nghĩa mới, bao hàm toàn bộ quá trình phát triển IP phức tạp. Giờ đây, thuật ngữ CASE tools có nghĩa là các công cụ phần mềm hỗ trợ các quá trình tạo và duy trì IS, bao gồm phân tích và hình thành các yêu cầu, thiết kế phần mềm ứng dụng (ứng dụng) và cơ sở dữ liệu, tạo mã, kiểm tra, tài liệu, đảm bảo chất lượng, quản lý cấu hình và dự án quản lý và các quy trình khác. Các công cụ CASE cùng với phần mềm hệ thống và phần cứng tạo thành một môi trường phát triển IS hoàn chỉnh.

Sự xuất hiện của công nghệ CASE và các công cụ CASE được đặt trước bởi nghiên cứu trong lĩnh vực phương pháp lập trình. Lập trình đã có được các tính năng của phương pháp tiếp cận hệ thống với việc phát triển và triển khai các ngôn ngữ cấp cao, các phương pháp lập trình cấu trúc và mô-đun, các ngôn ngữ thiết kế và các phương tiện hỗ trợ của chúng, các ngôn ngữ chính thức và không chính thức để mô tả các yêu cầu và thông số kỹ thuật của hệ thống, Vân vân. Ngoài ra, sự xuất hiện của công nghệ CASE đã được tạo điều kiện bởi các yếu tố như:

đào tạo các nhà phân tích và lập trình viên dễ tiếp thu các khái niệm lập trình mô-đun và cấu trúc;

sự giới thiệu rộng rãi và sự tăng trưởng không ngừng của năng suất máy tính, giúp sử dụng các công cụ đồ họa hiệu quả và tự động hóa hầu hết các công đoạn thiết kế;

giới thiệu công nghệ mạng, giúp kết hợp nỗ lực của từng người thực hiện vào một quy trình thiết kế duy nhất bằng cách sử dụng cơ sở dữ liệu dùng chung chứa thông tin cần thiết về dự án.

Công nghệ CASE là một phương pháp luận để thiết kế một IP, cũng như một bộ công cụ cho phép ở dạng trực quan.

Các công cụ CASE. Đặc điểm chung và phân loại

Các công cụ CASE hiện đại bao gồm nhiều lĩnh vực hỗ trợ cho nhiều công nghệ thiết kế vi mạch: từ các công cụ phân tích và tài liệu đơn giản đến các công cụ tự động hóa quy mô đầy đủ bao gồm toàn bộ vòng đời phần mềm.

Các giai đoạn phát triển IS tốn nhiều thời gian nhất là giai đoạn phân tích và thiết kế, trong đó các công cụ CASE đảm bảo chất lượng của các quyết định kỹ thuật được đưa ra và việc chuẩn bị tài liệu dự án. Đồng thời, các phương pháp trình bày thông tin trực quan đóng một vai trò quan trọng. Điều này liên quan đến việc xây dựng các sơ đồ cấu trúc hoặc các sơ đồ khác trong thời gian thực, sử dụng bảng màu đa dạng và kiểm tra các quy tắc cú pháp từ đầu đến cuối. Các công cụ đồ họa để mô hình hóa lĩnh vực chủ đề cho phép các nhà phát triển nghiên cứu trực quan IS hiện có, xây dựng lại nó phù hợp với các mục tiêu đã đặt ra và các ràng buộc hiện có.

Loại công cụ CASE bao gồm cả hệ thống tương đối rẻ cho máy tính cá nhân với khả năng rất hạn chế và hệ thống đắt tiền cho nền tảng máy tính và môi trường hoạt động không đồng nhất. Do đó, thị trường phần mềm hiện đại có khoảng 300 công cụ CASE khác nhau, công cụ mạnh nhất trong số đó được hầu hết các công ty hàng đầu phương Tây sử dụng theo cách này hay cách khác.

Thông thường, các công cụ CASE bao gồm bất kỳ công cụ phần mềm nào tự động hóa một tập hợp các quy trình vòng đời phần mềm cụ thể và có các tính năng đặc trưng chính sau:

các công cụ đồ họa mạnh mẽ để mô tả và lập tài liệu IP, cung cấp giao diện thuận tiện với nhà phát triển và phát triển khả năng sáng tạo của họ;

tích hợp các thành phần riêng lẻ của các công cụ CASE, cung cấp khả năng kiểm soát của quá trình phát triển IS;

sử dụng một kho lưu trữ siêu dữ liệu dự án được tổ chức đặc biệt (kho lưu trữ).

Một công cụ CASE tích hợp (hoặc một bộ công cụ hỗ trợ vòng đời hoàn chỉnh của phần mềm) chứa các thành phần sau;

kho lưu trữ là cơ sở của công cụ CASE. Nó phải cung cấp khả năng lưu trữ các phiên bản của dự án và các thành phần riêng lẻ của dự án, đồng bộ hóa luồng thông tin từ các nhà phát triển khác nhau trong quá trình phát triển nhóm, kiểm soát siêu dữ liệu để hoàn thiện và nhất quán;

các công cụ đồ họa để phân tích và thiết kế, cung cấp việc tạo và chỉnh sửa các sơ đồ liên quan đến phân cấp (DFD, ERD, v.v.) tạo thành các mô hình IS;

các công cụ phát triển ứng dụng, bao gồm ngôn ngữ 4GL và trình tạo mã;

công cụ quản lý cấu hình;

công cụ tài liệu;

công cụ kiểm tra;

công cụ quản lý dự án;

công cụ tái cấu trúc.

Tất cả các công cụ CASE hiện đại có thể được phân loại chủ yếu theo loại và danh mục. Phân loại theo loại phản ánh định hướng chức năng của công cụ CASE đối với các quá trình vòng đời nhất định. Việc phân loại theo danh mục xác định mức độ tích hợp theo các chức năng được thực hiện và bao gồm các công cụ cục bộ riêng biệt để giải quyết các nhiệm vụ tự quản nhỏ (công cụ), một tập hợp các công cụ tích hợp một phần bao gồm hầu hết các giai đoạn của vòng đời IS (bộ công cụ) và các công cụ được tích hợp đầy đủ hỗ trợ toàn bộ vòng đời của IS và được liên kết bởi một kho lưu trữ chung ... Ngoài ra, các công cụ CASE có thể được phân loại theo các tiêu chí sau:

các phương pháp luận và mô hình hệ thống và cơ sở dữ liệu áp dụng;

mức độ tích hợp với DBMS;

các nền tảng có sẵn.

Việc phân loại theo loại về cơ bản trùng với thành phần cấu thành của CASE-tools và bao gồm các loại chính sau:

các công cụ phân tích (Upper CASE) được thiết kế để xây dựng và phân tích các mô hình miền (Design / IDEF (Meta Software), BPwin (Logic Works));

các công cụ phân tích và thiết kế (Middle CASE) hỗ trợ các phương pháp thiết kế phổ biến nhất và được sử dụng để tạo các thông số kỹ thuật thiết kế (Vantage Team Builder (Cayenne), Designer / 2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE. Nhà phân tích (MacroProject)). Đầu ra của các công cụ đó là đặc tả của các thành phần và giao diện hệ thống, kiến ​​trúc hệ thống, thuật toán và cấu trúc dữ liệu;

các công cụ thiết kế cơ sở dữ liệu cung cấp mô hình hóa dữ liệu và tạo lược đồ cơ sở dữ liệu (thường là trong SQL) cho DBMS phổ biến nhất. ĐẾN bao gồm các ERwin (Công trình logic), S-Designor (SDP) và DataBase Designer (ORACLE). Các công cụ thiết kế cơ sở dữ liệu cũng có sẵn như một phần của các công cụ Vantage Team Builder, Designer / 2000, Silverrun và PRO-IV CASE;

các công cụ phát triển ứng dụng. Chúng bao gồm các công cụ 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer / 2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland), v.v.) và mã trình tạo bao gồm trong Vantage Team Builder, PRO-IV và một phần trong Silverrun;

các công cụ tái cấu trúc cung cấp phân tích mã chương trình và lược đồ cơ sở dữ liệu và hình thành các mô hình và đặc điểm thiết kế khác nhau trên cơ sở chúng. Các công cụ phân tích lược đồ cơ sở dữ liệu và tạo ERD được bao gồm trong Vantage Team Builder, PRO-IV, Silverrun, Designer / 2000, ERwin và S-Designor. Trong lĩnh vực phân tích mã chương trình, các công cụ CASE hướng đối tượng cung cấp khả năng tái cấu trúc các chương trình C ++ (Rational Rose (Phần mềm Rational), Nhóm đối tượng (Cayenne)) được sử dụng rộng rãi nhất.

Các loại trợ giúp bao gồm:

các công cụ lập kế hoạch và quản lý dự án (SE Companion, Microsoft Project, v.v.);

công cụ quản lý cấu hình (PVCS (Intersolv));

công cụ kiểm tra (Chất lượng Công trình (Phần mềm Segue));

công cụ tài liệu (SoDA (Rational Software)).

Ngày nay, thị trường phần mềm Nga có các công cụ CASE phát triển nhất sau đây:

Vantage Team Builder (Westmount I-CASE);

Nhà thiết kế / 2000;

Silverrun;

ERwin + BPwin;

Nhà thiết kế S;

TÌNH HUỐNG. Nhà phân tích.

Ngoài ra, các hệ thống mới cho người dùng trong nước liên tục xuất hiện trên thị trường (ví dụ: CASE / 4/0, PRO-IV, System Architect, Visible Analyst Workbench, EasyCASE), cũng như các phiên bản và sửa đổi mới của các hệ thống này.

1. Các nguyên tắc cơ bản của phương pháp thiết kế vi mạch

1.1. Vòng đời phần mềm vi mạch

Một trong những khái niệm cơ bản của phương pháp luận thiết kế IS là khái niệm về vòng đời của phần mềm của nó (phần mềm vòng đời). Vòng đời của phần mềm là một quá trình liên tục bắt đầu từ thời điểm đưa ra quyết định về sự cần thiết phải tạo ra nó và kết thúc tại thời điểm nó được rút khỏi dịch vụ hoàn toàn.

Văn bản quy định chính điều chỉnh vòng đời của phần mềm là tiêu chuẩn quốc tế ISO / IEC 12207 (ISO - International Organization of Standardization - Tổ chức Tiêu chuẩn hóa Quốc tế, IEC - International Electrotechnical Commission - Ủy ban Kỹ thuật Điện Quốc tế). Nó xác định cấu trúc của vòng đời, chứa các quy trình, hành động và nhiệm vụ phải được thực hiện trong quá trình tạo phần mềm.

Cấu trúc vòng đời của phần mềm theo tiêu chuẩn ISO / IEC 12207 dựa trên ba nhóm quy trình:

các quy trình vòng đời chính của phần mềm (mua, phân phối, phát triển, vận hành, bảo trì);

các quá trình phụ trợ đảm bảo việc thực hiện các quá trình chính (tài liệu, quản lý cấu hình, đảm bảo chất lượng, xác minh, chứng nhận, đánh giá, đánh giá, giải quyết vấn đề);

các quy trình của tổ chức (quản lý dự án, tạo cơ sở hạ tầng dự án, định nghĩa, đánh giá và cải thiện chính vòng đời, đào tạo).

Phát triển bao gồm tất cả các công việc về việc tạo ra phần mềm và các thành phần của nó phù hợp với các yêu cầu cụ thể, bao gồm cả việc chuẩn bị thiết kế và tài liệu vận hành, chuẩn bị các tài liệu cần thiết để kiểm tra khả năng hoạt động và chất lượng thích hợp của các sản phẩm phần mềm, các tài liệu cần thiết để tổ chức đào tạo nhân sự, Vân vân. Phát triển phần mềm thường bao gồm phân tích, thiết kế và triển khai (lập trình).

Hoạt động bao gồm công việc về việc triển khai các thành phần phần mềm vào hoạt động, bao gồm định cấu hình cơ sở dữ liệu và máy trạm của người dùng, cung cấp tài liệu vận hành, đào tạo nhân viên, v.v. và vận hành trực tiếp, bao gồm bản địa hóa các vấn đề và loại bỏ nguyên nhân xảy ra chúng, sửa đổi phần mềm trong quy định, chuẩn bị các đề xuất cải tiến, phát triển và hiện đại hóa hệ thống.

Quản lý dự án liên quan đến việc lập kế hoạch và tổ chức công việc, thành lập các nhóm phát triển và kiểm soát thời gian và chất lượng công việc được thực hiện. Hỗ trợ kỹ thuật và tổ chức của dự án bao gồm việc lựa chọn các phương pháp và công cụ để thực hiện dự án, định nghĩa các phương pháp mô tả các trạng thái phát triển trung gian, phát triển các phương pháp và công cụ để kiểm thử phần mềm, đào tạo nhân sự, v.v. Đảm bảo chất lượng dự án gắn liền với các vấn đề kiểm tra, xác minh và thử nghiệm phần mềm. Xác minh là quá trình xác định xem trạng thái phát triển hiện tại đạt được ở một giai đoạn nhất định có đáp ứng các yêu cầu của giai đoạn đó hay không. Xác minh cho phép bạn đánh giá sự tuân thủ của các thông số phát triển với các yêu cầu ban đầu. Xác minh trùng lặp với kiểm tra, liên quan đến việc xác định sự khác biệt giữa kết quả thực tế và kết quả mong đợi và đánh giá sự phù hợp của các đặc tính phần mềm với các yêu cầu ban đầu. Trong quá trình thực hiện dự án, một vị trí quan trọng bị chiếm bởi các vấn đề về xác định, mô tả và kiểm soát cấu hình của các thành phần riêng lẻ và toàn bộ hệ thống nói chung.

Quản lý cấu hình là một trong những quy trình phụ trợ hỗ trợ các quy trình chính của vòng đời phần mềm, chủ yếu là các quy trình phát triển và bảo trì phần mềm. Khi tạo các dự án IS phức tạp, bao gồm nhiều thành phần, mỗi thành phần có thể có nhiều loại hoặc phiên bản, vấn đề nảy sinh là phải tính đến các kết nối và chức năng của chúng, tạo ra một cấu trúc thống nhất và đảm bảo sự phát triển của toàn bộ hệ thống. Quản lý cấu hình cho phép bạn tổ chức, tính đến hệ thống và kiểm soát các thay đổi của phần mềm ở tất cả các giai đoạn của vòng đời. Các nguyên tắc và khuyến nghị chung về kế toán cấu hình, lập kế hoạch và quản lý cấu hình phần mềm được phản ánh trong dự thảo tiêu chuẩn ISO 12207-2.

Mỗi quy trình được đặc trưng bởi các nhiệm vụ và phương pháp giải pháp nhất định của chúng, dữ liệu ban đầu thu được ở giai đoạn trước và kết quả. Đặc biệt, kết quả phân tích là các mô hình chức năng, mô hình thông tin và các sơ đồ tương ứng của chúng. Vòng đời của phần mềm có tính chất lặp lại: kết quả của giai đoạn tiếp theo thường gây ra những thay đổi trong các giải pháp thiết kế được phát triển ở giai đoạn trước đó.

2. Cách tiếp cận cấu trúc đối với thiết kế vi mạch CASE có nghĩa là

2.1. Bản chất của cách tiếp cận cấu trúc

Bản chất của cách tiếp cận cấu trúc đối với sự phát triển của IS nằm ở việc phân rã (phân chia) nó thành các chức năng tự động: hệ thống được chia thành các hệ thống con chức năng, lần lượt được chia thành các chức năng con, chia thành các nhiệm vụ, v.v. Quá trình phân vùng tiếp tục xuống các thủ tục cụ thể. Đồng thời, hệ thống tự động vẫn giữ được cái nhìn tổng thể, trong đó tất cả các bộ phận cấu thành được kết nối với nhau. Khi phát triển một hệ thống "từ dưới lên" từ các nhiệm vụ riêng lẻ đến toàn bộ hệ thống, tính toàn vẹn bị mất, các vấn đề nảy sinh trong việc cập nhật thông tin của các thành phần riêng lẻ.

Tất cả các phương pháp luận tiếp cận cấu trúc phổ biến nhất đều dựa trên một số nguyên tắc chung. Sau đây là hai nguyên tắc cơ bản:

nguyên tắc “chia để trị” - nguyên tắc giải quyết các vấn đề phức tạp bằng cách chia nhỏ chúng thành nhiều vấn đề nhỏ độc lập dễ hiểu và dễ giải quyết;

nguyên tắc sắp xếp thứ bậc - nguyên tắc tổ chức các bộ phận cấu thành của một vấn đề thành các cấu trúc cây có thứ bậc với việc bổ sung các chi tiết mới ở mỗi cấp độ.

Làm nổi bật hai nguyên tắc cơ bản không có nghĩa là các nguyên tắc còn lại là thứ yếu, vì việc bỏ qua bất kỳ nguyên tắc nào trong số đó có thể dẫn đến những hậu quả khó lường (bao gồm cả sự thất bại của toàn bộ dự án). Các nguyên tắc chính của những nguyên tắc này như sau:

nguyên tắc trừu tượng - bao gồm việc làm nổi bật các khía cạnh thiết yếu của hệ thống và trừu tượng khỏi những điều không đáng kể;

nguyên tắc chính thức hóa - nằm ở chỗ cần có một phương pháp luận chặt chẽ để giải quyết vấn đề;

nguyên tắc nhất quán - bao gồm hiệu lực và tính nhất quán của các yếu tố;

nguyên tắc của cấu trúc dữ liệu là dữ liệu phải được cấu trúc và tổ chức phân cấp.

Trong phân tích cấu trúc, chủ yếu có hai nhóm công cụ minh họa các chức năng được thực hiện bởi hệ thống và các mối quan hệ giữa các dữ liệu. Mỗi nhóm quỹ tương ứng với một số loại mô hình (sơ đồ) nhất định, trong đó phổ biến nhất là các mô hình sau:

Các mô hình SADT (Kỹ thuật phân tích và thiết kế có cấu trúc) và các sơ đồ chức năng tương ứng (tiểu mục 2.2);

Sơ đồ luồng dữ liệu DFD (Data Flow Diagrams) (tiểu mục 2.3);

ERD (Entity-Relationship Sơ đồ) sơ đồ "thực thể-mối quan hệ" (tiểu mục 2.4).

Ở giai đoạn thiết kế IS, các mô hình được mở rộng, tinh chỉnh và bổ sung các sơ đồ phản ánh cấu trúc của phần mềm: kiến ​​trúc phần mềm, sơ đồ khối chương trình và sơ đồ màn hình.

Các mô hình được liệt kê cùng nhau đưa ra mô tả đầy đủ về IP, bất kể nó đang tồn tại hay mới được phát triển. Thành phần của các sơ đồ trong từng trường hợp cụ thể phụ thuộc vào mức độ đầy đủ cần thiết của mô tả hệ thống.

2.2. Phương pháp lập mô hình chức năng SADT ( IDEF 0)

Phương pháp SADT được phát triển bởi Douglas Ross. Đặc biệt, trên cơ sở đó, phương pháp luận IDEF0 (Icam DEFinition) nổi tiếng đã được phát triển, là phần chính của chương trình ICAM (Tích hợp Máy tính và Công nghệ Công nghiệp) do Không quân Hoa Kỳ khởi xướng.

Phương pháp luận SADT là một tập hợp các phương pháp, quy tắc và thủ tục được thiết kế để xây dựng một mô hình chức năng của một đối tượng thuộc bất kỳ lĩnh vực chủ đề nào. Mô hình chức năng SADT phản ánh cấu trúc chức năng của đối tượng, tức là các hành động do anh ta thực hiện và mối liên hệ giữa các hành động này. Các yếu tố chính của phương pháp luận này dựa trên các khái niệm sau:

biểu diễn đồ họa của mô hình khối. Khối SADT và đồ họa vòng cung hiển thị một chức năng dưới dạng một khối, và các giao diện I / O được biểu diễn bằng các vòng cung vào và ra khối tương ứng. Sự tương tác của các khối với nhau được mô tả bằng các vòng cung giao diện thể hiện các "ràng buộc", từ đó xác định thời điểm và cách thức các chức năng được thực hiện và kiểm soát;

chặt chẽ và chính xác. Việc tuân thủ các quy tắc SADT đòi hỏi phải đủ nghiêm ngặt và chính xác mà không đặt ra những ràng buộc quá mức đối với hành động của nhà phân tích. Các quy tắc SADT bao gồm:

giới hạn số khối ở mỗi cấp độ phân hủy (quy tắc 3-6 khối);

kết nối sơ đồ (số khối);

tính duy nhất của nhãn và tên (không có tên trùng lặp);

quy tắc cú pháp cho đồ họa (khối và vòng cung);

tách biệt các yếu tố đầu vào và kiểm soát (quy tắc xác định vai trò của dữ liệu).

tách tổ chức khỏi chức năng, tức là loại bỏ ảnh hưởng của cơ cấu tổ chức đối với mô hình chức năng.

Phương pháp luận SADT có thể được sử dụng để mô hình hóa nhiều loại hệ thống và xác định các yêu cầu và chức năng, sau đó thiết kế một hệ thống đáp ứng các yêu cầu này và thực hiện các chức năng đó. Đối với các hệ thống hiện có, SADT có thể được sử dụng để phân tích các chức năng được thực hiện bởi hệ thống, cũng như chỉ ra các cơ chế mà chúng được thực hiện.

2.2.1. Thành phần mô hình chức năng

Kết quả của việc áp dụng phương pháp SADT là một mô hình bao gồm các sơ đồ, các đoạn văn bản và bảng thuật ngữ được liên kết với nhau. Sơ đồ là thành phần chính của mô hình, tất cả các chức năng và giao diện IC trên chúng được biểu diễn dưới dạng khối và vòng cung. Kết nối giữa vòng cung và khối xác định loại giao diện. Thông tin điều khiển đi vào khối từ trên cùng, trong khi thông tin đang được xử lý được hiển thị ở phía bên trái của khối và kết quả đầu ra được hiển thị ở phía bên phải. Cơ chế (con người hoặc hệ thống tự động) thực hiện hoạt động được biểu diễn bằng một vòng cung đi vào khối từ bên dưới (Hình 2.1).

Một trong những đặc điểm quan trọng nhất của phương pháp SADT là việc đưa dần các mức chi tiết cao hơn vào khi các biểu đồ đại diện cho mô hình được tạo ra.

Lúa gạo. 2.1. Khối chức năng và vòng cung giao diện

Hình 2.2 cho thấy bốn sơ đồ và mối quan hệ của chúng, cho thấy cấu trúc của mô hình SADT. Mỗi thành phần của mô hình có thể được phân tách thành một sơ đồ khác nhau. Mỗi sơ đồ minh họa "cấu trúc bên trong" của một khối trong sơ đồ mẹ.

2.2.2. Thứ bậc của biểu đồ

Xây dựng mô hình SADT bắt đầu bằng việc biểu diễn toàn bộ hệ thống như một thành phần đơn giản - một khối duy nhất và các vòng cung thể hiện các giao diện với các chức năng bên ngoài hệ thống. Vì một khối duy nhất đại diện cho toàn bộ hệ thống nói chung nên tên được đặt trong khối là phổ biến. Điều này cũng đúng với các vòng cung giao diện - chúng cũng đại diện cho toàn bộ tập hợp các giao diện bên ngoài của hệ thống nói chung.

Sau đó, khối, đại diện cho hệ thống như một đơn vị duy nhất, được trình bày chi tiết trong một sơ đồ khác bằng cách sử dụng một số khối được kết nối bằng các vòng cung giao diện. Các khối này đại diện cho các chức năng con chính của chức năng ban đầu. Sự phân tách này cho thấy một tập hợp đầy đủ các chức năng con, mỗi chức năng được biểu diễn dưới dạng một khối, ranh giới của chúng được xác định bởi các vòng cung giao diện. Mỗi chức năng con này có thể được phân tách tương tự nhau để trình bày chi tiết hơn.

Trong mọi trường hợp, mỗi hàm con chỉ có thể chứa những phần tử được bao gồm trong hàm ban đầu. Ngoài ra, mô hình không thể bỏ qua bất kỳ phần tử nào, tức là, như đã được lưu ý, khối mẹ và các giao diện của nó cung cấp ngữ cảnh. Không có gì có thể được thêm vào nó, và không có gì có thể được xóa khỏi nó.

Mô hình SADT là một chuỗi các biểu đồ với tài liệu đi kèm chia nhỏ một đối tượng phức tạp thành các phần thành phần của nó, được trình bày dưới dạng các khối. Chi tiết của từng khối chính được hiển thị như các khối trong các sơ đồ khác. Mỗi sơ đồ chi tiết là sự phân rã của một khối từ một sơ đồ tổng quát hơn. Ở mỗi bước phân rã, sơ đồ tổng quát hơn được gọi là sơ đồ mẹ cho sơ đồ chi tiết hơn.

Các vòng cung đi vào và ra khỏi khối trong sơ đồ cấp cao nhất hoàn toàn giống với các cung đi vào và ra khỏi sơ đồ cấp dưới, vì khối và biểu đồ đại diện cho cùng một phần của hệ thống.

Lúa gạo. 2.2. Cấu trúc mô hình SADT. Sự phân rã của biểu đồ

Hình 2.3 - 2.5 cho thấy các tùy chọn khác nhau để thực hiện các chức năng và kết nối các vòng cung với các khối.

Lúa gạo. 2.3. Thực hiện đồng thời

Lúa gạo. 2.4. Tuân thủ phải đầy đủ và nhất quán

Một số vòng cung được gắn vào các khối sơ đồ bằng cả hai đầu, trong khi những vòng cung khác không gắn một đầu. Các cung không kết nối tương ứng với các đầu vào, điều khiển và đầu ra của khối cha. Nguồn hoặc đích của các cung đường biên này chỉ có thể được tìm thấy trong sơ đồ mẹ. Các đầu không kết nối phải khớp với các vòng cung trong sơ đồ ban đầu. Tất cả các cung đường biên phải tiếp tục trên sơ đồ mẹ để nó hoàn chỉnh và nhất quán.

Biểu đồ SADT không chỉ ra trình tự hoặc thời gian một cách rõ ràng. Phản hồi, lặp lại, quy trình đang diễn ra và các chức năng chồng chéo (trong thời gian) có thể được mô tả bằng cách sử dụng các vòng cung. Phản hồi có thể ở dạng nhận xét, nhận xét, sửa chữa, v.v. (Hình 2.5).

Lúa gạo. 2.5. Ví dụ về phản hồi

Như đã lưu ý, các cơ chế (vòng cung ở mặt dưới) hiển thị các phương tiện mà các chức năng được thực hiện. Cơ chế có thể là con người, máy tính hoặc bất kỳ thiết bị nào khác giúp thực hiện chức năng này (Hình 2.6).

Lúa gạo. 2.6. Ví dụ về cơ chế

Mỗi khối trong sơ đồ được đánh số. Một khối của bất kỳ sơ đồ nào có thể được mô tả thêm bằng một sơ đồ cấp thấp hơn, đến lượt nó, có thể được chi tiết hơn bằng cách sử dụng số lượng sơ đồ cần thiết. Do đó, một sơ đồ phân cấp được hình thành.

Để chỉ ra vị trí của bất kỳ biểu đồ hoặc khối nào trong hệ thống phân cấp, số biểu đồ được sử dụng. Ví dụ, A21 là một sơ đồ chi tiết khối 1 trong sơ đồ A2. Tương tự, A2 chi tiết khối 2 trong sơ đồ A0, là sơ đồ trên cùng của mô hình. Hình 2.7 cho thấy một cây sơ đồ điển hình.

Lúa gạo. 2.7. Thứ bậc của biểu đồ

2.2.3. Các loại liên kết giữa các chức năng

Một trong những điểm quan trọng trong việc thiết kế vi mạch sử dụng phương pháp luận SADT là tính nhất quán chính xác của các loại mối quan hệ giữa các chức năng. Có ít nhất bảy loại ràng buộc:

Dưới đây, mỗi loại liên kết được định nghĩa ngắn gọn và minh họa bằng một ví dụ điển hình từ SADT.

(0) Kiểu kết nối ngẫu nhiên: ít mong muốn nhất.

Kết nối ngẫu nhiên xảy ra khi có rất ít hoặc không có kết nối cụ thể giữa các chức năng. Điều này đề cập đến tình huống mà các tên dữ liệu trên các cung SADT trong cùng một sơ đồ có rất ít mối quan hệ với nhau. Một phiên bản cực đoan của trường hợp này được thể hiện trong Hình 2.8.

Lúa gạo. 2.8. Kết nối ngẫu nhiên

(1) Loại kết nối logic.Khớp nối logic xảy ra khi dữ liệu và các hàm được kết hợp với nhau do thực tế là chúng thuộc một lớp hoặc tập hợp các phần tử chung, nhưng không tìm thấy các mối quan hệ chức năng cần thiết giữa chúng.

(2) Loại kết nối thời gian.Các mục liên quan đến thời gian phát sinh vì chúng đại diện cho các chức năng liên quan đến thời gian, khi dữ liệu được sử dụng đồng thời hoặc khi các chức năng được đưa vào song song thay vì tuần tự.

(3) Loại kết nối thủ tục.Các mục liên quan đến thủ tục xuất hiện được nhóm lại với nhau do thực tế là chúng được thực thi trong cùng một phần của một chu trình hoặc quy trình. Một ví dụ về sơ đồ liên kết theo thủ tục được thể hiện trong Hình 2.9.

Lúa gạo. 2.9. Kết nối thủ tục

(4) Loại kết nối giao tiếp.Các sơ đồ minh họa mối quan hệ giao tiếp khi các khối được nhóm lại do chúng sử dụng cùng một dữ liệu đầu vào và / hoặc tạo ra cùng một dữ liệu đầu ra (Hình 2.10).

(5) Loại kết nối nối tiếp.Trong sơ đồ có kết nối nối tiếp, đầu ra của một chức năng đóng vai trò là đầu vào cho chức năng tiếp theo. Mối quan hệ giữa các yếu tố trong biểu đồ gần gũi hơn so với các cấp độ kết nối đã thảo luận ở trên, vì các mối quan hệ nhân quả được mô hình hóa (Hình 2.11).

(6) Loại kết nối chức năng.Biểu đồ phản ánh kết nối đầy đủ chức năng, khi có sự phụ thuộc hoàn toàn của chức năng này vào chức năng khác. Sơ đồ, hoàn toàn là chức năng, không chứa các yếu tố ngoại lai liên quan đến kiểu kết nối tuần tự hoặc yếu hơn. Một cách để xác định các sơ đồ liên quan đến chức năng là xem xét hai khối được kết nối thông qua các vòng cung điều khiển, như trong Hình 2.12.

Lúa gạo. 2.10. Kết nối giao tiếp

Lúa gạo. 2.11. Kết nối tuần tự

Hình 13. Sơ đồ chức năng để tạo và sửa đổi một dự án sản phẩm (cấp độ thứ hai)

Để dễ đọc, nên giới hạn số lượng khối trong sơ đồ ở mức từ ba đến sáu. Giới hạn trên buộc bạn phải dùng đến phân rã, giới hạn dưới đảm bảo rằng có đủ chi tiết trong sơ đồ để đảm bảo việc tạo ra nó. Điều mong muốn là số lượng cung giao diện tiếp cận hoặc phát ra từ phía khối không được vượt quá 4.

IDEF Phương pháp 0 giả định làm việc nhómqua một dự án hoặc các dự án. Một nhóm đa chuyên môn phỏng vấn những cá nhân có năng lực và xây dựng một mô hình thô. Mô hình này được thảo luận bởi các chuyên gia doanh nghiệp, phản biện bằng văn bản và chuyển cho nhóm phát triển. Chu kỳ này tiếp tục cho đến khi các nhà phát triển và người đánh giá có cùng quan điểm. Tiếp theo là việc phê duyệt chính thức mô hình và việc sử dụng nó (ví dụ, để cơ cấu lại các chức năng của hệ thống).

Một trong những ưu điểm của phương pháp IDEF 0 là nó tóm tắt từcơ cấu tổ chức của cơ sởvà phân tích các chức năng của nó. Điều này cho phép, sau khi xây dựng mô hình, xem xét cơ cấu tổ chức thực hiện các chức năng này từ quan điểm hoàn thiện của nó, xác định các chức năng tương tự hoặc sự trùng lặp của chúng và đưa ra các đề xuất tổ chức lại hệ thống.

Nếu chúng ta sử dụng thuật ngữ "quy trình kinh doanh", thì chúng ta có thể nói rằng phương pháp IDEF 0 cho phép bạn xác địnhquy trình kinh doanh, xem xét hoạt động của doanh nghiệp "như nó vốn có" và trên cơ sở phân tích của họ, đưa ra đề xuất "nó nên như thế nào", nghĩa là, có một cái nhìn mới mẻ về công việc của doanh nghiệp, làm rõ trách nhiệm của nhân viên, đánh giá hiệu quả sử dụng nguồn lực, nhìn ra những thiếu sót được che giấu một cách khéo léo trong cơ cấu tổ chức thông thường. Do đó, xác định, phân tích và thực hiện các thay đổi đối với các quy trình kinh doanh có thể được sử dụng để nâng cao hiệu quả của doanh nghiệp.

Kể từ khi thuật ngữ "quy trình kinh doanh" ra đời, một số kỹ thuật đã xuất hiện để cải thiện quy trình kinh doanh. Phổ biến nhất trong số này là tái cấu trúc quy trình kinh doanh của doanh nghiệp, liên quan đến việc suy nghĩ lại cơ bản và thiết kế lại các quy trình kinh doanh của doanh nghiệp. Xác định, phân tích và thiết kế lại các quá trình này là nội dung của phương pháp luận được đề xuất. Sơ đồ chung về phương pháp luận để phân tích và tổ chức lại các quy trình kinh doanh của một doanh nghiệp như sau (xem Hình 12):

Thu thập thông tin về công ty;

• xác định các quy trình kinh doanh của một doanh nghiệp và tạo ra một mô hình chức năng của các quy trình kinh doanh của một doanh nghiệp;
• phân tích và có thể tái cấu trúc các quy trình kinh doanh của doanh nghiệp.

Để phân tích chia sẻ chi phíphương pháp ABC dựa trên IDEF0 được áp dụng. Phương pháp ABC dựa trên thực tế là việc thực hiện từng chức năng trong quá trình hoạt động của doanh nghiệp đều có một khoản chi phí nhất định, tức là nó góp phần làm phát sinh chi phí. ABC tương tự như khái niệm của FSA - phân tích chi phí theo chức năng. Sử dụng phương pháp ABC, chi phí thực hiện toàn bộ quá trình hoặc một chức năng riêng biệt được tính toán, giá thành sản phẩm ở đầu ra của quá trình và nguồn của chi phí chính được xác định. Chi phí thực hiện một chức năng phân rã được định nghĩa là tổng chi phí thực hiện tất cả các phần tử cấu thành trong chức năng đó.

Sử dụng phương pháp ABC cung cấp các đánh giá quá trình định lượng cần thiết để đánh giá nhiều lựa chọn. Không giống như kế toán truyền thống chủ yếu tính đến chi phí trực tiếp (việc hạch toán chi phí gián tiếp rất khó nhưng trong một số trường hợp là cần thiết), phương pháp ABC cho phép bạn tính đến nhiều yếu tố khác nhau ảnh hưởng đến việc hình thành chi phí doanh nghiệp.

Để xây dựng một mô hình chức năng, người ta đề xuất lựa chọn Gói CASE Thiết kế / IDEF , vì ngoài khả năng tạo mô hình chức năng, gói này còn chứa một cơ chế tích hợp để tính toán chi phí tính toán chi phí thực hiện các chức năng, cho phép bạn phân tích các quy trình kinh doanh và các thành phần của chúng. Mỗi loại tài nguyên được tiêu thụ (xử lý) bởi một chức năng, cũng như các cơ chế thực hiện chức năng, đều làm tăng giá trị cho chức năng này, đồng thời tính đến các yếu tố chi phí bị bỏ qua theo quan điểm thông thường của doanh nghiệp như một tập hợp các cơ cấu tổ chức . Do đó, mỗi hàm h của mô hình IDEF0 có thể được liên kết với giá trị của chi phí thực hiện hàm này Ex (h).

Hình 14. Sơ đồ chung về phương pháp luận để phân tích và tổ chức lại các quy trình kinh doanh của doanh nghiệp

Sự kết hợp của phương pháp IDEF0 và ABC (Hình 14) cho phép giải quyết một trong những nhiệm vụ quan trọng nhất - phân tích mức độ hoàn thiện của các chức năng hệ thống, khả năng cải tiến nó, điều không phải là đặc trưng của các phương pháp và tiêu chuẩn khác.Kết nối phương pháp ABC cho phép bạn so sánh cấu trúc hiện có (như nó vốn có) với một cấu trúc hợp lý (đúng như vậy), vì các chức năng giống nhau có thể được thực hiện bởi các cấu trúc khác nhau (ví dụ: bạn có thể kết hợp các phòng ban thực hiện các chức năng tương tự với một sự khác biệt không đáng kể hoặc khối lượng công việc thấp).

Một ví dụ về xây dựng fMô hình chức năng của quá trình tạo CAD được thể hiện trong Hình 15 ... 18.

Hình 15. Mô hình chức năng của quá trình tạo CAD (bắt đầu).
IDEF 0-sơ đồ của mức đầu tiên.

Hình 16. IDEF 0 là biểu đồ khảo sát doanh nghiệp.

Hình 17. IDEF Sơ đồ thiết kế 0-CAD.

Hình 18. IDEF Sơ đồ 0 của việc thực hiện dự án CAD.

2.3. Mô hình hóa luồng dữ liệu (quy trình - mô hình DFD, IDEF tiêu chuẩn 1)

Phương pháp này (phương pháp Gane / Sarson) dựa trên việc xây dựng một mô hình của IS đã phân tích - được dự kiến ​​hoặc thực sự tồn tại. Theo phương pháp luận, mô hình hệ thống được định nghĩa là một sơ đồ luồng dữ liệu phân cấp (DFD hoặc DFD), mô tả quá trình chuyển đổi không đồng bộ thông tin từ đầu vào của nó vào hệ thống thành thông tin được cấp cho người dùng. Sơ đồ các cấp trên của hệ thống phân cấp (sơ đồ ngữ cảnh) xác định các quy trình chính hoặc hệ thống con của IS với các đầu vào và đầu ra bên ngoài. Chúng được trình bày chi tiết bằng cách sử dụng sơ đồ cấp thấp. Sự phân hủy này tiếp tục, tạo ra một sơ đồ phân cấp nhiều cấp độ, cho đến khi đạt đến mức độ phân hủy như vậy, tại đó quá trình trở thành sơ cấp và không thể chi tiết hóa chúng thêm nữa.

IDEF1- phương pháp mô hình hóaluồng thông tin trong hệ thống,cho phép hiển thị cấu trúc của hệ thống, nghĩa là các phần tử (thực thể) của nó, các thuộc tính (thuộc tính) và các mối quan hệ (mối quan hệ) giữa chúng. Thông tin chi tiết thu được trong quá trình mô hình hóa giúp xác định các điểm nghẽn trong đối tượng được phân tích và là cơ sở để đưa ra quyết định cải tiến cấu trúc của hệ thống và các luồng thông tin, thực hiện chính sách quản lý thông tin đúng đắn.

Các nguồn thông tin (các thực thể bên ngoài) tạo ra các luồng thông tin (luồng dữ liệu) mang thông tin đến các hệ thống con hoặc các quá trình. Đến lượt nó, chúng biến đổi thông tin và tạo ra các luồng mới chuyển thông tin đến các quy trình hoặc hệ thống con khác, thiết bị lưu trữ dữ liệu hoặc các thực thể bên ngoài - người tiêu dùng thông tin. Do đó, các thành phần chính của sơ đồ luồng dữ liệu là:

các thực thể bên ngoài;

hệ thống / hệ thống con;

các quy trình;

thiết bị lưu trữ dữ liệu;

các luồng dữ liệu.

2.3.1. Các thực thể bên ngoài

Một thực thể bên ngoài là một vật phẩm hoặc cá nhân vật chất là nguồn hoặc người nhận thông tin, ví dụ, khách hàng, nhân sự, nhà cung cấp, khách hàng, kho hàng. Định nghĩa của một số đối tượng hoặc hệ thống như một thực thể bên ngoài chỉ ra rằng nó nằm ngoài ranh giới của IS được phân tích. Trong quá trình phân tích, một số thực thể bên ngoài có thể được chuyển vào bên trong sơ đồ IS đã phân tích, nếu cần, hoặc ngược lại, một số quy trình IS có thể được chuyển ra bên ngoài sơ đồ và được trình bày như một thực thể bên ngoài.

Thực thể bên ngoài được biểu thị bằng một hình vuông (Hình 2.13), nằm như thể "phía trên" sơ đồ và đổ bóng lên nó, để biểu tượng này có thể được phân biệt với các ký hiệu khác:

Lúa gạo. 2.13. Thực thể bên ngoài

2.3.2. Hệ thống và hệ thống con

Khi xây dựng một mô hình IS phức tạp, nó có thể được trình bày dưới dạng tổng quát nhất trên cái gọi là sơ đồ ngữ cảnh như một hệ thống tổng thể, hoặc nó có thể được phân tách thành một số hệ thống con.

Hệ thống con (hoặc hệ thống) trên sơ đồ ngữ cảnh được mô tả như sau (Hình 2.14).

Lúa gạo. 2,14. Hệ thống con

Số hệ thống con được sử dụng để xác định nó. Trong trường tên, tên của hệ thống con được nhập dưới dạng một câu với chủ đề và các định nghĩa và bổ sung tương ứng.

2.3.3. Quy trình

Quá trình là sự biến đổi các luồng dữ liệu đầu vào thành đầu ra phù hợp với một thuật toán nhất định. Về mặt vật lý, quy trình có thể được thực hiện theo nhiều cách khác nhau: nó có thể là một phần nhỏ của một tổ chức (bộ phận) xử lý tài liệu đầu vào và phát hành báo cáo, một chương trình, một thiết bị logic được triển khai bằng phần cứng, v.v.

Quá trình được mô tả trong một sơ đồ luồng dữ liệu như trong Hình 2.15.

Lúa gạo. 2,15. Tiến trình

Số quy trình được sử dụng để xác định nó. Trong trường tên, hãy nhập tên của quá trình dưới dạng một câu với động từ rõ ràng đang hoạt động ở dạng không xác định (tính toán, tính toán, kiểm tra, xác định, tạo, nhận được), theo sau là danh từ trong trường hợp buộc tội, chẳng hạn. :

"Nhập thông tin khách hàng";

"Phát hành thông tin về chi phí hiện tại";

"Kiểm tra mức độ tín nhiệm của khách hàng".

Việc sử dụng các động từ như "quá trình", "hiện đại hóa" hoặc "chỉnh sửa" thường có nghĩa là không có đủ hiểu biết sâu sắc về quá trình này và cần phải phân tích thêm.

Thông tin trong trường triển khai vật lý cho biết đơn vị tổ chức, chương trình hoặc thiết bị phần cứng nào đang thực hiện quy trình.

2.3.4. Lưu trữ dữ liệu

Thiết bị lưu trữ dữ liệu là một thiết bị trừu tượng để lưu trữ thông tin có thể được đặt vào thiết bị lưu trữ bất cứ lúc nào và sau một thời gian có thể lấy ra được, và các phương pháp đặt và truy xuất có thể là bất kỳ.

Thiết bị lưu trữ dữ liệu có thể được thực hiện vật lý dưới dạng một microfiche, một hộp trong tủ hồ sơ, một bảng trong RAM, một tệp trên phương tiện từ tính, v.v. Kho dữ liệu được mô tả trong một sơ đồ luồng dữ liệu như trong Hình 2.16.

Lúa gạo. 2,16. Lưu trữ dữ liệu

Thiết bị lưu trữ dữ liệu được xác định bằng chữ "D" và một số tùy ý. Tên của ổ đĩa được chọn vì lý do cung cấp nhiều thông tin nhất cho người thiết kế.

Nói chung, kho lưu trữ dữ liệu là một nguyên mẫu của cơ sở dữ liệu trong tương lai và mô tả về dữ liệu được lưu trữ trong đó nên được liên kết với mô hình thông tin.

2.3.5. Các luồng dữ liệu

Luồng dữ liệu xác định thông tin được truyền qua kết nối từ nguồn đến bồn rửa. Luồng dữ liệu thực tế có thể là thông tin được truyền qua cáp giữa hai thiết bị, thư được gửi qua đường bưu điện, băng từ hoặc đĩa mềm được truyền từ máy tính này sang máy tính khác, v.v.

Luồng dữ liệu trong biểu đồ được biểu diễn bằng một đường kết thúc bằng mũi tên chỉ hướng của luồng (Hình 2.17). Mỗi luồng dữ liệu có một tên phản ánh nội dung của nó.

Lúa gạo. 2.17. Dòng dữ liệu

2.3.6. Xây dựng sơ đồ luồng dữ liệu phân cấp

Bước đầu tiên trong việc xây dựng hệ thống phân cấp DPD là xây dựng sơ đồ ngữ cảnh. Thông thường, khi thiết kế các vi mạch tương đối đơn giản, một sơ đồ ngữ cảnh đơn với cấu trúc liên kết hình sao được xây dựng, ở trung tâm của nó là quy trình chính, được kết nối với các máy thu và các nguồn thông tin mà qua đó người dùng và các hệ thống bên ngoài khác tương tác. với hệ thống.

Nếu chúng ta tự giới hạn mình trong một sơ đồ ngữ cảnh duy nhất cho một hệ thống phức tạp, thì nó sẽ chứa quá nhiều nguồn và người nhận thông tin khó có thể sắp xếp trên một tờ giấy có định dạng thông thường, và bên cạnh đó, quy trình chính duy nhất không tiết lộ cấu trúc của một hệ thống phân tán. Các chỉ số về độ phức tạp (theo ngữ cảnh) có thể là:

sự hiện diện của một số lượng lớn các thực thể bên ngoài (mười hoặc nhiều hơn);

bản chất phân tán của hệ thống;

tính đa chức năng của hệ thống với một nhóm chức năng đã được thiết lập hoặc xác định thành các hệ thống con riêng biệt.

Đối với các IS phức tạp, một sơ đồ ngữ cảnh phân cấp được xây dựng. Đồng thời, sơ đồ ngữ cảnh cấp cao nhất không chứa một quy trình chính duy nhất mà là một tập hợp các hệ thống con được kết nối bởi các luồng dữ liệu. Biểu đồ ngữ cảnh cấp tiếp theo trình bày chi tiết ngữ cảnh và cấu trúc của các hệ thống con.

Hệ thống phân cấp của sơ đồ ngữ cảnh xác định sự tương tác của các hệ thống con chức năng chính của IS được thiết kế với nhau và với các luồng dữ liệu đầu vào và đầu ra bên ngoài và các đối tượng bên ngoài (nguồn và người nhận thông tin) mà IS tương tác với nhau.

Việc phát triển các sơ đồ ngữ cảnh giải quyết vấn đề xác định chặt chẽ cấu trúc chức năng của IS ở giai đoạn đầu của quá trình thiết kế, điều này đặc biệt quan trọng đối với các hệ thống đa chức năng phức tạp, trong quá trình phát triển có nhiều tổ chức và nhóm phát triển khác nhau tham gia.

Sau khi xây dựng sơ đồ ngữ cảnh, mô hình kết quả cần được kiểm tra tính đầy đủ của dữ liệu ban đầu về các đối tượng của hệ thống và sự cô lập của các đối tượng (không có liên kết thông tin với các đối tượng khác).

Đối với mỗi hệ thống con hiện diện trên các sơ đồ ngữ cảnh, chi tiết của nó được thực hiện bằng cách sử dụng DPD. Đến lượt từng quy trình trên DPD, có thể được chi tiết hóa bằng cách sử dụng DPD hoặc phân tích nhỏ. Khi trình bày chi tiết, phải tuân theo các quy tắc sau:

quy tắc cân bằng - có nghĩa là khi mô tả chi tiết một hệ thống con hoặc quá trình, một sơ đồ chi tiết với tư cách là nguồn / bộ nhận dữ liệu bên ngoài chỉ có thể có các thành phần đó (hệ thống con, quy trình, thực thể bên ngoài, kho lưu trữ dữ liệu) mà hệ thống con chi tiết hoặc quy trình trên sơ đồ mẹ có một kết nối thông tin;

quy tắc đánh số - có nghĩa là khi trình bày chi tiết các quy trình, việc đánh số thứ bậc của chúng nên được hỗ trợ. Ví dụ: các quy trình chi tiết hóa quy trình số 12 được đánh số 12.1, 12.2, 12.3, v.v.

Mô tả nhỏ (mô tả logic của quá trình) nên hình thành các chức năng chính của nó theo cách mà trong tương lai chuyên gia thực hiện dự án có thể thực hiện chúng hoặc phát triển một chương trình thích hợp.

Minispec là đỉnh cuối cùng của phân cấp DPD. Nhà phân tích quyết định hoàn thành chi tiết quy trình và sử dụng minispec dựa trên các tiêu chí sau:

quy trình có số lượng luồng dữ liệu đầu vào và đầu ra tương đối nhỏ (2-3 luồng);

khả năng mô tả sự biến đổi dữ liệu của một quá trình dưới dạng một thuật toán tuần tự;

thực hiện theo quy trình của một hàm logic duy nhất chuyển đổi thông tin đầu vào thành đầu ra;

khả năng mô tả logic của quy trình bằng cách sử dụng một thông số kỹ thuật nhỏ nhỏ (không quá 20-30 dòng).

Khi xây dựng hệ thống phân cấp của DPD, người ta chỉ nên tiến hành chi tiết các quy trình sau khi xác định nội dung của tất cả các luồng và thiết bị lưu trữ dữ liệu, được mô tả bằng cách sử dụng cấu trúc dữ liệu. Cấu trúc dữ liệu được xây dựng từ các mục dữ liệu và có thể chứa các lựa chọn thay thế, điều kiện và lặp lại. Mục nhập có điều kiện có nghĩa là thành phần này có thể không có trong cấu trúc. Thay thế có nghĩa là cấu trúc có thể bao gồm một trong các phần tử được liệt kê. Lặp lại có nghĩa là đi qua bất kỳ số phần tử nào trong phạm vi được chỉ định. Đối với mỗi phần tử dữ liệu, loại của nó (dữ liệu liên tục hoặc rời rạc) có thể được chỉ ra. Đối với dữ liệu liên tục, đơn vị đo (kg, cm, v.v.), phạm vi giá trị, độ chính xác của biểu diễn và hình thức mã hóa vật lý có thể được chỉ ra. Đối với dữ liệu rời rạc, một bảng các giá trị có thể chấp nhận được có thể được chỉ định.

Sau khi xây dựng một mô hình hoàn chỉnh của hệ thống, nó phải được xác nhận (kiểm tra tính đầy đủ và nhất quán). Trong một mô hình hoàn chỉnh, tất cả các đối tượng của nó (hệ thống con, quy trình, luồng dữ liệu) phải được mô tả cụ thể và chi tiết. Các đối tượng không chi tiết được tiết lộ nên được chi tiết hóa bằng cách quay lại các bước phát triển trước đó. Trong một mô hình nhất quán, tất cả các luồng dữ liệu và thiết bị lưu trữ dữ liệu phải tuân thủ quy tắc lưu giữ thông tin: tất cả dữ liệu đến một nơi nào đó phải được đọc và tất cả dữ liệu đã đọc phải được ghi.

2.4. Mô hình dữ liệu

IDEF1X- Phương pháp lập mô hình dữ liệu và thiết kế cơ sở dữ liệu quan hệ... Nó thuộc về loại phương pháp luận mối quan hệ thực thể ( ER - Thực thể - Mối quan hệ ), tuy nhiên, các thực thể ở đây không được hiểu là các đối tượng thực, mà là các kiểu của chúng với các thuộc tính chung. Mối quan hệ giữa các thực thể phức tạp hơn. Điều này cho phép thông tin được lưu trữ dưới dạng một lược đồ trừu tượng (mô hình ngữ nghĩa) kết nối các ký hiệu được lưu trữ trong máy tính với thế giới thực và là sự phản ánh trung thực của nó. Cách lưu trữ thông tin này tương đối độc lập, "trung lập" và cho phép bạn nhận được câu trả lời cho các truy vấn khác nhau của người dùng về các thuộc tính của môi trường được mô tả trong mô hình. Tiêu chuẩn IDEF1X được phát hành vào năm 1993 ( FIPS 184).

2.4.1. Phương pháp trường hợp của Barker

Mục đích của mô hình hóa dữ liệu là cung cấp cho nhà phát triển IS một lược đồ cơ sở dữ liệu khái niệm dưới dạng một mô hình duy nhất hoặc nhiều mô hình cục bộ có thể được ánh xạ tương đối dễ dàng tới bất kỳ hệ thống cơ sở dữ liệu nào.

Công cụ mô hình hóa dữ liệu phổ biến nhất là sơ đồ mối quan hệ-thực thể (ERD). Với sự trợ giúp của họ, các đối tượng (thực thể) quan trọng đối với lĩnh vực chủ thể được xác định, các thuộc tính (thuộc tính) và quan hệ của chúng với nhau (kết nối). ERD được sử dụng trực tiếp để thiết kế cơ sở dữ liệu quan hệ.

Ký hiệu ERD lần đầu tiên được giới thiệu bởi P. Chen và được phát triển thêm bởi Barker. Phương pháp của Barker sẽ được trình bày trên ví dụ về mô hình hóa các hoạt động của một công ty kinh doanh xe hơi. Dưới đây là trích đoạn cuộc phỏng vấn với nhân sự công ty.

Tổng giám đốc: Một trong những trách nhiệm chính là bảo dưỡng tài sản ô tô. Anh ta cần biết số tiền được trả cho những chiếc xe và chi phí chung là bao nhiêu. Với thông tin này, anh ta có thể đặt giá thấp hơn mà anh ta có thể bán một bản sao nhất định. Ngoài ra, anh ta chịu trách nhiệm về những người bán và anh ta cần biết ai đang bán cái gì và bao nhiêu chiếc xe mỗi người trong số họ đã bán.

Người bán: anh ta cần biết giá để yêu cầu và giá thấp nhất mà giao dịch có thể được thực hiện. Ngoài ra, anh ta cần thông tin cơ bản về xe: năm sản xuất, nhà sản xuất, kiểu xe, v.v.

Quản trị viên: nhiệm vụ của anh ta được giảm xuống việc lập các hợp đồng, đòi hỏi thông tin về người mua, xe và người bán, vì các hợp đồng mang lại phần thưởng cho người bán khi bán hàng.

Bước đầu tiên trong mô hình hóa là trích xuất thông tin từ các cuộc phỏng vấn và trích xuất các thực thể.

Thực thể - một đối tượng thực hoặc tưởng tượng cần thiết cho lĩnh vực chủ đề được xem xét, thông tin về đối tượng đó sẽ được lưu trữ (Hình 2.18).

Lúa gạo. 2.18. Biểu diễn đồ họa của một thực thể

Mỗi thực thể phải có một định danh duy nhất. Mỗi cá thể của một thực thể phải được xác định duy nhất và khác biệt với tất cả các cá thể khác của loại thực thể đó. Mỗi thực thể phải có một số thuộc tính:

mỗi thực thể phải có một tên duy nhất và cách diễn giải giống nhau phải luôn được áp dụng cho cùng một tên. Không thể áp dụng cùng một cách diễn giải cho các tên khác nhau, trừ khi chúng là bí danh;

một thực thể có một hoặc nhiều thuộc tính thuộc về thực thể hoặc được kế thừa thông qua một mối quan hệ;

một thực thể có một hoặc nhiều thuộc tính xác định duy nhất từng thể hiện của thực thể;

mỗi thực thể có thể có bất kỳ mối quan hệ nào với các thực thể khác trong mô hình.

Đề cập đến các trích đoạn phỏng vấn trên, rõ ràng các đối tượng có thể được xác định với tổng giám đốc là xe và nhân viên bán hàng. Người bán quan tâm đến xe và dữ liệu liên quan đến việc bán của họ. Đối với nhà quản trị, người mua, phương tiện, người bán và hợp đồng là quan trọng. Dựa trên cơ sở này, 4 thực thể được phân biệt (xe, người bán, người mua, hợp đồng), được mô tả trong sơ đồ như sau (Hình 2.19).

Lúa gạo. 2,19.

Bước tiếp theo trong mô hình hóa là xác định các liên kết.

Mối quan hệ - một liên kết được đặt tên giữa hai thực thể có ý nghĩa quan trọng đối với miền đang được xem xét. Mối quan hệ là sự liên kết giữa các thực thể, trong đó, như một quy luật, mỗi cá thể của một thực thể, được gọi là thực thể mẹ, được liên kết với một số lượng tùy ý (bao gồm cả 0) các phiên bản của thực thể thứ hai, được gọi là thực thể con và mỗi thể hiện của thực thể con được liên kết chính xác với một thể hiện của thực thể mẹ. Do đó, một thể hiện của một thực thể con chỉ có thể tồn tại nếu thực thể mẹ tồn tại.

Liên kết có thể được đặt một cái tên được thể hiện bằng cách chuyển ngữ pháp của động từ và được đặt gần liên kết. Tên của mỗi mối quan hệ giữa hai thực thể này phải là duy nhất, nhưng tên mối quan hệ trong mô hình không cần phải là duy nhất. Tên của mối quan hệ luôn được hình thành theo quan điểm của cha mẹ, do đó, một câu có thể được tạo thành bằng cách ghép tên của thực thể mẹ, tên của mối quan hệ, sự phát triển của mức độ và tên của thực thể con cháu.

Ví dụ, mối quan hệ của người bán đối với hợp đồng có thể được thể hiện như sau:

người bán có thể nhận được phần thưởng cho 1 hoặc nhiều hợp đồng;

hợp đồng phải được bắt đầu bởi chính xác một người bán.

Mức độ kết nối và cam kết được mô tả bằng đồ thị như sau (Hình 2.20).

Lúa gạo. 2,20.

Như vậy, 2 câu mô tả mối quan hệ giữa người bán và hợp đồng sẽ được thể hiện bằng đồ thị như sau (Hình 2.21).

Lúa gạo. 2,21.

Sau khi mô tả các kết nối của các thực thể còn lại, chúng ta có được sơ đồ sau (Hình 2.22).

Lúa gạo. 2,22.

Bước cuối cùng trong mô hình hóa là xác định các thuộc tính.

Thuộc tính - bất kỳ đặc điểm nào của thực thể có ý nghĩa đối với lĩnh vực chủ thể được xem xét và nhằm xác định chất lượng, nhận dạng, phân loại, đặc điểm định lượng hoặc biểu hiện trạng thái của đơn vị. Thuộc tính đại diện cho một loại đặc điểm hoặc thuộc tính được liên kết với nhiều đối tượng thực hoặc trừu tượng (người, địa điểm, sự kiện, trạng thái, ý tưởng, cặp đối tượng, v.v.). Một thể hiện thuộc tính là một đặc tính cụ thể của một phần tử riêng lẻ của một tập hợp. Một thể hiện thuộc tính được xác định bởi kiểu đặc tính và giá trị của nó, được gọi là giá trị thuộc tính. Trong mô hình ER, các thuộc tính được liên kết với các thực thể cụ thể. Do đó, một cá thể thực thể phải có một giá trị xác định, duy nhất cho thuộc tính được liên kết.

Thuộc tính có thể là bắt buộc hoặc tùy chọn (Hình 2.23). Bắt buộc có nghĩa là thuộc tính không được nhận giá trị rỗng. Thuộc tính có thể là mô tả (tức là trình mô tả thực thể thông thường) hoặc một phần của mã định danh duy nhất (khóa chính).

Bộ nhận dạng độc đáolà một thuộc tính hoặc một tập hợp các thuộc tính và / hoặc các mối quan hệ được thiết kế để xác định duy nhất từng trường hợp của một loại thực thể nhất định. Trong trường hợp nhận dạng hoàn toàn, mỗi cá thể của loại thực thể này được nhận dạng đầy đủ bằng các thuộc tính chính của chính nó, nếu không các thuộc tính của thực thể mẹ khác cũng tham gia vào việc nhận dạng nó (Hình 2.24).

Lúa gạo. 2,23.

Lúa gạo. 2,24.

Mỗi thuộc tính được xác định bằng một cụm danh từ duy nhất mô tả đặc tính được đại diện bởi thuộc tính. Các thuộc tính được hiển thị dưới dạng danh sách tên trong khối thực thể được liên kết, với mỗi thuộc tính nằm trên một dòng riêng biệt. Các thuộc tính xác định khóa chính được đặt ở đầu danh sách và được đánh dấu bằng dấu "#".

Mỗi thực thể phải có ít nhất một khóa khả thi. Khóa thực thể có thể có là một hoặc nhiều thuộc tính có giá trị nhận dạng duy nhất từng cá thể thực thể. Nếu có nhiều khóa khả thi, một trong số chúng được chỉ định làm khóa chính và những khóa khác được chỉ định làm khóa thay thế.

Có tính đến các thông tin sẵn có, chúng tôi sẽ bổ sung sơ đồ đã xây dựng trước đó (Hình 2.25).

Ngoài các cấu trúc cơ bản được liệt kê, một mô hình dữ liệu có thể chứa một số cấu trúc bổ sung.

Kiểu phụ và kiểu siêu nhỏ:một thực thể là một khái niệm tổng quát cho một nhóm các thực thể giống nhau (Hình 2.26).

Mối quan hệ loại trừ lẫn nhau:mỗi thể hiện của một thực thể chỉ tham gia vào một mối quan hệ từ một nhóm các mối quan hệ loại trừ lẫn nhau (Hình 2.27).

Lúa gạo. 2,25.

Lúa gạo. 2.26. Kiểu phụ và kiểu siêu nhỏ

Lúa gạo. 2.27. Mối quan hệ loại trừ lẫn nhau

Liên kết đệ quy:một thực thể có thể liên quan đến chính nó (Hình 2.28).

Các liên kết không thể chuyển nhượng:một cá thể thực thể không thể được chuyển từ thể hiện quan hệ này sang thể hiện quan hệ khác (Hình 2.29).

Lúa gạo. 2.28. Liên kết đệ quy

Lúa gạo. 2.29. Liên kết bất động

2.4.2. Phương pháp IDEF1

Phương pháp IDEF1, do T.Ramey phát triển, cũng dựa trên cách tiếp cận của P. Chen và cho phép bạn xây dựng mô hình dữ liệu tương đương với mô hình quan hệ ở dạng chuẩn thứ ba. Hiện tại, dựa trên sự cải tiến của phương pháp IDEF1, một phiên bản mới đã được tạo ra - phương pháp IDEF1X. IDEF1X được thiết kế với mục đích dễ học và tự động hóa. Sơ đồ IDEF1X được sử dụng bởi một số công cụ CASE phổ biến (cụ thể là ERwin, Design / IDEF).

Một thực thể trong phương pháp luận IDEF1X độc lập với số nhận dạng hoặc đơn giản là độc lập nếu mỗi phiên bản của một thực thể có thể được nhận dạng duy nhất mà không cần xác định mối quan hệ của nó với các thực thể khác. Một thực thể được gọi là phụ thuộc định danh hoặc phụ thuộc đơn giản nếu việc nhận dạng duy nhất của một cá thể thực thể phụ thuộc vào mối quan hệ của nó với một thực thể khác (Hình 2.30).

Lúa gạo. 2,30. Thực thể

Mỗi thực thể được gán một tên và số duy nhất, được phân tách bằng dấu gạch chéo "/" và được đặt phía trên khối.

Mối quan hệ có thể được xác định thêm bằng cách chỉ định mức độ hoặc số lượng (số lượng cá thể của thực thể con có thể tồn tại cho mỗi phiên bản của thực thể mẹ). Các bản số sau có thể được thể hiện trong IDEF1X:

mỗi cá thể thực thể mẹ có thể không có, một hoặc nhiều cá thể thực thể con được liên kết với nó;

mỗi cá thể thực thể mẹ phải có ít nhất một cá thể thực thể con được liên kết;

mỗi cá thể thực thể mẹ phải có nhiều nhất một cá thể thực thể con được liên kết;

mỗi cá thể thực thể mẹ được liên kết với một số cá thể thực thể con cố định.

Nếu một trường hợp của một thực thể con được xác định duy nhất bởi mối quan hệ của nó với thực thể mẹ, thì mối quan hệ đó được gọi là nhận dạng, nếu không thì nó là không xác định.

Mối quan hệ được mô tả bằng một đường kẻ giữa thực thể mẹ và thực thể con với một dấu chấm ở cuối dòng tại thực thể con. Nguồn điện giao tiếp được chỉ ra như trong hình. 2,31 (công suất mặc định - N).

Lúa gạo. 2,31. Sức mạnh truyền thông

Mối quan hệ xác định giữa thực thể mẹ và thực thể con được mô tả bằng một đường liền nét (Hình 2.32). Một thực thể con trong mối quan hệ nhận dạng là một thực thể phụ thuộc vào số nhận dạng. Thực thể mẹ trong mối quan hệ nhận dạng có thể là một thực thể độc lập hoặc một thực thể phụ thuộc vào số nhận dạng (điều này được xác định bởi các mối quan hệ của nó với các thực thể khác).

Lúa gạo. 2,32. Xác định mối quan hệ

Đường chấm chấm thể hiện mối quan hệ không xác định (Hình 2.33). Một thực thể con trong mối quan hệ không nhận dạng sẽ độc lập với định danh nếu nó cũng không phải là một thực thể con trong bất kỳ mối quan hệ nhận dạng nào.

Lúa gạo. 2,33. Mối quan hệ không xác định

Các thuộc tính được hiển thị dưới dạng danh sách tên bên trong khối thực thể. Các thuộc tính xác định khóa chính được đặt ở đầu danh sách và ngăn cách với các thuộc tính khác bằng một đường ngang (Hình 2.34).

Lúa gạo. 2,34. Thuộc tính và khóa chính

Các thực thể cũng có thể có Khóa ngoại, có thể được sử dụng như một phần hoặc toàn bộ của khóa chính hoặc thuộc tính không phải khóa. Khóa ngoại được mô tả bằng cách đặt tên thuộc tính bên trong khối thực thể, theo sau là các chữ cái FK trong dấu ngoặc (Hình 2.35).

Lúa gạo. 2,35. Ví dụ về khóa ngoại

2.5. Một ví dụ về việc sử dụng phương pháp tiếp cận có cấu trúc

2.5.1. Mô tả lĩnh vực chủ đề

Ví dụ này sử dụng phương pháp Yourdon được triển khai trong công cụ Vantage Team Builder CASE.

Lĩnh vực chủ đề là mô tả về cách thức hoạt động của thư viện video, thư viện này nhận các yêu cầu về phim từ khách hàng và băng do khách hàng trả lại. Yêu cầu được quản trị thư viện video xem xét bằng cách sử dụng thông tin về khách hàng, phim và băng. Thao tác này sẽ kiểm tra và cập nhật danh sách các băng đã cho thuê, và kiểm tra hồ sơ thành viên của thư viện. Cơ quan quản lý cũng giám sát việc trả lại băng, sử dụng thông tin về phim, băng và danh sách các băng đã thuê, được cập nhật. Xử lý yêu cầu phim và trả lại băng bao gồm các bước sau: Nếu khách hàng không phải là thành viên của thư viện, họ không được quyền thuê. Nếu có sẵn phim theo yêu cầu, ban quản lý sẽ thông báo cho khách hàng về giá thuê. Tuy nhiên, nếu khách hàng đã quá thời hạn trả lại băng mà mình có thì không được phép lấy phim mới. Khi cuộn băng được trả lại, ban quản lý sẽ tính tiền thuê cộng với phí trả chậm.

Thư viện video nhận được các băng mới từ các nhà cung cấp của nó. Khi những cuốn băng mới đến thư viện, những thông tin cần thiết về chúng sẽ được ghi lại. Thông tin thành viên thư viện được giữ riêng biệt với hồ sơ thuê băng.

Ban quản trị thư viện thường xuyên chuẩn bị các báo cáo trong một khoảng thời gian về các thành viên thư viện, nhà cung cấp băng, băng cụ thể đã phát hành và băng do thư viện mua.

2.5.2. Tổ chức của dự án

Toàn bộ dự án được chia thành 4 giai đoạn: phân tích, thiết kế toàn cục (thiết kế kiến ​​trúc hệ thống), thiết kế chi tiết và triển khai (lập trình).

Trong giai đoạn phân tích, một Mô hình Môi trường được xây dựng. Xây dựng mô hình môi trường bao gồm:

• phân tích hành vi của hệ thống (xác định mục đích của IS, xây dựng sơ đồ luồng dữ liệu ngữ cảnh ban đầu (DFD) và hình thành danh sách ma trận sự kiện (ELM), xây dựng sơ đồ ngữ cảnh);
• phân tích dữ liệu (xác định thành phần của luồng dữ liệu và xây dựng sơ đồ cấu trúc dữ liệu (DSD), xây dựng mô hình dữ liệu toàn cục dưới dạng biểu đồ ER).

Mục đích của IP xác định thỏa thuận giữa các nhà thiết kế và khách hàng về mục đích của IP trong tương lai, mô tả chung về IP cho chính các nhà thiết kế và ranh giới của IP. Bài tập được ghi lại dưới dạng nhận xét văn bản trong quy trình sơ đồ ngữ cảnh "null".

Ví dụ, trong trường hợp này, mục đích của IP được xây dựng như sau: duy trì cơ sở dữ liệu về các thành viên thư viện, phim, phim cho thuê và nhà cung cấp. Đồng thời, ban quản lý thư viện cần có khả năng nhận được các loại báo cáo để hoàn thành nhiệm vụ của mình.

Trước khi xây dựng DFD theo ngữ cảnh, cần phải phân tích các sự kiện bên ngoài (các đối tượng bên ngoài) có ảnh hưởng đến hoạt động của thư viện. Các đối tượng này tương tác với IS thông qua trao đổi thông tin với nó.

Từ mô tả về lĩnh vực chủ đề, có thể thấy các nhóm người sau đây tham gia vào hoạt động của thư viện: khách hàng, nhà cung cấp và ban quản lý. Các nhóm này là các đối tượng bên ngoài. Chúng không chỉ tương tác với hệ thống mà còn xác định ranh giới của nó và được mô tả trên DFD theo ngữ cảnh ban đầu dưới dạng các đầu cuối (các thực thể bên ngoài).

Sơ đồ ngữ cảnh ban đầu được thể hiện trong Hình 2.42. Không giống như ký hiệu Gane / Sarson, các thực thể bên ngoài được biểu thị bằng hình chữ nhật thông thường và các quy trình được biểu thị bằng hình tròn.

Lúa gạo. 2.42. Sơ đồ ngữ cảnh ban đầu

Danh sách các sự kiện được xây dựng dưới dạng ma trận (ELM) và mô tả các hành động khác nhau của các thực thể bên ngoài và phản hồi của IP đối với chúng. Các hành động này là các sự kiện bên ngoài ảnh hưởng đến thư viện. Các loại sự kiện sau được phân biệt:

Tất cả các hành động được đánh dấu là dữ liệu bình thường. Những dữ liệu này là những sự kiện mà IS trực tiếp nhận thấy, ví dụ như sự thay đổi trong địa chỉ của khách hàng, địa chỉ này phải được đăng ký ngay lập tức. Chúng xuất hiện trong DFD dưới dạng nội dung của các luồng dữ liệu.

Ma trận danh sách sự kiện như sau:

Để hoàn thành việc phân tích khía cạnh chức năng của hành vi của hệ thống, một sơ đồ ngữ cảnh hoàn chỉnh được xây dựng, bao gồm cả một sơ đồ mức không. Trong trường hợp này, quy trình "thư viện" được phân tách thành 4 quy trình, phản ánh các loại hoạt động quản trị chính của thư viện. Các luồng dữ liệu "trừu tượng" hiện có giữa các trình kết thúc và quy trình được chuyển đổi thành các luồng đại diện cho việc trao đổi dữ liệu ở mức cụ thể hơn. Danh sách các sự kiện cho biết những luồng nào tồn tại ở cấp độ này: mỗi sự kiện từ danh sách phải tạo thành một luồng nhất định (một sự kiện tạo thành một luồng đầu vào, một phản ứng - một luồng đầu ra). Một luồng "trừu tượng" có thể được chia thành nhiều luồng "cụ thể".

Trong DFD đã cho (Hình 2.43), "thư viện" kho dữ liệu là một đại diện toàn cục hoặc trừu tượng của kho dữ liệu.

Việc phân tích khía cạnh chức năng của hành vi của hệ thống đưa ra ý tưởng về việc trao đổi và chuyển đổi dữ liệu trong hệ thống. Mối quan hệ giữa dòng dữ liệu "trừu tượng" và dòng dữ liệu "cụ thể" trong sơ đồ mức 0 được thể hiện trong sơ đồ cấu trúc dữ liệu (Hình 2.44).

Ở giai đoạn phân tích, một mô hình dữ liệu toàn cục được xây dựng, biểu diễn dưới dạng biểu đồ mối quan hệ-thực thể (Hình 2.45).

Các mối quan hệ sau đây tồn tại giữa các loại biểu đồ khác nhau:

• ELM-DFD: sự kiện - luồng đầu vào, phản ứng - luồng đầu ra
• DFD-DSD: Luồng dữ liệu - Cấu trúc dữ liệu cấp cao nhất
• DFD-ERD: Ổ đĩa dữ liệu - Sơ đồ ER
• DSD-ERD: Cấu trúc dữ liệu cấp thấp hơn - Thuộc tính thực thể

Trong giai đoạn thiết kế kiến ​​trúc, một mô hình chủ thể được xây dựng. Quá trình xây dựng mô hình chủ đề bao gồm:

• mô tả chi tiết về hoạt động của hệ thống;
• phân tích sâu hơn về dữ liệu được sử dụng và xây dựng mô hình dữ liệu logic cho thiết kế cơ sở dữ liệu tiếp theo;
• xác định cấu trúc của giao diện người dùng, đặc điểm kỹ thuật của các biểu mẫu và thứ tự xuất hiện của chúng;
• làm rõ sơ đồ luồng dữ liệu và danh sách các sự kiện, làm nổi bật tính tương tác và không tương tác giữa các quy trình cấp thấp hơn, xác định các thông số kỹ thuật nhỏ cho chúng.

Lúa gạo. 2.43. Sơ đồ ngữ cảnh

Lúa gạo. 2.44. Sơ đồ cấu trúc dữ liệu

Kết quả của thiết kế kiến ​​trúc là:

• mô hình quy trình (sơ đồ kiến ​​trúc hệ thống (SAD) và các thông số kỹ thuật nhỏ trong ngôn ngữ có cấu trúc);
• mô hình dữ liệu (ERD và ERD subcircuits);
• mô hình giao diện người dùng (phân loại các quy trình thành các chức năng tương tác và không tương tác, Biểu đồ trình tự biểu mẫu (FSD), cho biết các biểu mẫu nào xuất hiện trong ứng dụng và theo thứ tự nào. Tập hợp và cấu trúc của các lệnh gọi màn hình được cố định trên FSD. Biểu đồ biểu đồ FSD một hệ thống phân cấp, ở trên cùng là biểu mẫu chính của ứng dụng, thực hiện hệ thống con, ở cấp thứ hai là các biểu mẫu thực hiện các quy trình ở cấp thấp hơn của cấu trúc chức năng, được cố định trên các sơ đồ SAD.

Lúa gạo. 2,45. Sơ đồ mối quan hệ thực thể

Trong giai đoạn thiết kế chi tiết, một mô hình mô-đun được xây dựng. Mô hình mô đun được hiểu là mô hình thực của hệ thống ứng dụng đã thiết kế. Quá trình xây dựng nó bao gồm:

• làm rõ mô hình cơ sở dữ liệu để tạo ra các câu lệnh SQL tiếp theo;
• làm rõ cấu trúc của giao diện người dùng;
• xây dựng các sơ đồ cấu trúc phản ánh logic của giao diện người dùng và mô hình logic nghiệp vụ (Sơ đồ cấu trúc - SCD) và sự ràng buộc của chúng với các biểu mẫu.

Kết quả thiết kế chi tiết là:

• mô hình quy trình (sơ đồ khối của các chức năng tương tác và không tương tác);
• mô hình dữ liệu (định nghĩa trong ERD của tất cả các tham số cần thiết cho các ứng dụng);
• một mô hình giao diện người dùng (một biểu đồ trình tự biểu mẫu (FSD) cho biết những biểu mẫu nào xuất hiện trong ứng dụng và theo thứ tự nào, mối quan hệ giữa mỗi biểu mẫu và một sơ đồ cấu trúc cụ thể, mối quan hệ giữa mỗi biểu mẫu và một hoặc nhiều thực thể trong ERD).

Trong giai đoạn thực hiện, một mô hình thực hiện được xây dựng. Quá trình xây dựng nó bao gồm:

• tạo các câu lệnh SQL xác định cấu trúc của cơ sở dữ liệu đích (bảng, chỉ mục, ràng buộc toàn vẹn);
• tinh chỉnh sơ đồ cấu trúc (SCD) và biểu đồ trình tự hình thức (FSD) với thế hệ mã ứng dụng tiếp theo.

Dựa trên việc phân tích các luồng dữ liệu và sự tương tác của các quy trình với kho dữ liệu, việc phân bổ các hệ thống con cuối cùng được thực hiện (sơ bộ lẽ ra phải được thực hiện và cố định ở giai đoạn hình thành các yêu cầu trong điều kiện tham chiếu). Khi phân bổ các hệ thống con, cần được hướng dẫn bởi nguyên tắc kết nối chức năng và nguyên tắc giảm thiểu sự phụ thuộc thông tin. Cần lưu ý rằng trên cơ sở các yếu tố của hệ thống con như các quy trình và dữ liệu ở giai đoạn phát triển, một ứng dụng phải được tạo ra có thể hoạt động độc lập. Mặt khác, khi nhóm các quy trình và dữ liệu thành các hệ thống con, cần phải tính đến các yêu cầu về cấu hình sản phẩm, nếu chúng được xây dựng trong giai đoạn phân tích.

Trong thập kỷ qua, một hướng mới trong kỹ thuật phần mềm đã được hình thành - CASE (Computer-Aided Software / System Engineering) - dịch theo nghĩa đen - phát triển phần mềm cho hệ thống thông tin với sự hỗ trợ (với sự trợ giúp) của máy tính. Hiện tại, không có định nghĩa chung được chấp nhận về CASE, thuật ngữ CASE được sử dụng với nghĩa rất rộng. Ý nghĩa ban đầu của thuật ngữ CASE, giới hạn trong các vấn đề tự động hóa chỉ phát triển phần mềm, giờ đây đã có một ý nghĩa mới, bao hàm toàn bộ quá trình phát triển các hệ thống thông tin tự động phức tạp. Giờ đây, thuật ngữ CASE tools có nghĩa là các công cụ phần mềm hỗ trợ các quá trình tạo và duy trì IS, bao gồm phân tích và hình thành các yêu cầu, thiết kế phần mềm ứng dụng (phần mềm) (ứng dụng) và cơ sở dữ liệu, tạo mã, kiểm tra, tài liệu, đảm bảo chất lượng , quản lý cấu hình và quản lý dự án cũng như các quy trình khác. Các công cụ CASE cùng với phần mềm hệ thống và phần cứng tạo thành một môi trường phát triển IS hoàn chỉnh.

Các công cụ CASE cho phép bạn không chỉ tạo ra các sản phẩm "đúng" mà còn cung cấp quy trình "đúng" cho việc tạo ra chúng. Mục tiêu chính của CASE là tách thiết kế của vi mạch khỏi mã hóa và các giai đoạn phát triển tiếp theo của nó, cũng như che giấu với các nhà phát triển tất cả các chi tiết về môi trường phát triển và hoạt động của vi mạch. Khi sử dụng công nghệ CASE, tất cả các giai đoạn của vòng đời phần mềm (sẽ thảo luận thêm về điều này bên dưới) của hệ thống thông tin thay đổi, trong khi những thay đổi lớn nhất liên quan đến các giai đoạn phân tích và thiết kế. Hầu hết các công cụ CASE hiện có đều dựa trên phương pháp phân tích và thiết kế cấu trúc (chủ yếu) hoặc hướng đối tượng, sử dụng các đặc tả dưới dạng sơ đồ hoặc văn bản để mô tả các yêu cầu bên ngoài, mối quan hệ giữa các mô hình hệ thống, động lực của hành vi hệ thống và kiến ​​trúc phần mềm. Các phương pháp luận như vậy cung cấp một mô tả chặt chẽ và mang tính mô tả về hệ thống đang được thiết kế, bắt đầu bằng cái nhìn tổng quan về hệ thống và sau đó đi vào chi tiết hơn, có được cấu trúc phân cấp với số lượng cấp ngày càng tăng. Các công nghệ CASE được sử dụng thành công để xây dựng hầu hết các loại IP, tuy nhiên, chúng chiếm một vị trí ổn định trong các lĩnh vực sau:

đảm bảo sự phát triển của IP kinh doanh và thương mại, việc sử dụng rộng rãi các công nghệ CASE là do tính chất rộng lớn của lĩnh vực ứng dụng này, trong đó CASE không chỉ được sử dụng để phát triển IP mà còn để tạo ra các mô hình hệ thống giúp giải quyết các vấn đề về hoạch định chiến lược, quản lý tài chính, xác định chính sách của công ty, đào tạo nhân sự và những vấn đề khác (lĩnh vực này được đặt tên riêng - phân tích kinh doanh);

phát triển hệ thống và điều khiển IS. Việc sử dụng tích cực các công nghệ CASE gắn liền với sự phức tạp lớn của vấn đề này và với mong muốn tăng hiệu quả công việc.

CASE không phải là một cuộc cách mạng trong kỹ thuật phần mềm, mà là kết quả của sự phát triển tiến hóa tự nhiên của toàn bộ ngành công cụ trước đây được gọi là công cụ hoặc công nghệ. Ngay từ đầu, công nghệ CASE đã phát triển để khắc phục những hạn chế của phương pháp thiết kế kết cấu trong những năm 1960 và 1970. Thế kỷ XX. (mức độ phức tạp của sự hiểu biết, cường độ lao động và chi phí sử dụng cao, khó khăn trong việc thay đổi thông số kỹ thuật thiết kế, v.v.) do chúng tự động hóa và tích hợp các công cụ hỗ trợ. Do đó, các công nghệ CASE không thể được coi là các phương pháp luận độc lập, chúng chỉ phát triển các phương pháp luận cấu trúc và làm cho ứng dụng của chúng hiệu quả hơn thông qua tự động hóa.

Ngoài việc tự động hóa các phương pháp luận cấu trúc và do đó, khả năng sử dụng các phương pháp hiện đại của kỹ thuật hệ thống và phần mềm, các công cụ CASE có những ưu điểm chính sau:

nâng cao chất lượng của IS đã tạo bằng phương pháp điều khiển tự động (trước hết là điều khiển dự án);

cho phép bạn tạo nguyên mẫu của một hệ thống tương lai trong thời gian ngắn, cho phép bạn đánh giá kết quả mong đợi ở giai đoạn đầu;

tăng tốc quá trình thiết kế và phát triển;

giải phóng nhà phát triển khỏi công việc thường ngày, cho phép anh ta tập trung hoàn toàn vào phần sáng tạo của quá trình phát triển;

hỗ trợ phát triển và duy trì sự phát triển;

hỗ trợ các công nghệ tái sử dụng thành phần phát triển.

Sự xuất hiện của công nghệ CASE và các công cụ CASE được đặt trước bởi nghiên cứu trong lĩnh vực phương pháp lập trình. Lập trình có được các tính năng của phương pháp tiếp cận hệ thống với việc phát triển và triển khai các ngôn ngữ cấp cao, phương pháp lập trình cấu trúc và mô-đun, ngôn ngữ thiết kế và phương tiện hỗ trợ của chúng, ngôn ngữ chính thức và không chính thức để mô tả các yêu cầu và thông số kỹ thuật của hệ thống, v.v. . một phương pháp cấu trúc đã được áp dụng trong thực tế, cung cấp cho các nhà phát triển các phương pháp chính thức hóa nghiêm ngặt để mô tả các giải pháp kỹ thuật và sở hữu trí tuệ. Nó dựa trên một kỹ thuật đồ họa trực quan: các lược đồ và sơ đồ được sử dụng để mô tả các loại mô hình IP khác nhau. Sự rõ ràng và chặt chẽ của các công cụ phân tích cấu trúc cho phép các nhà phát triển và người dùng tương lai của hệ thống ngay từ đầu tham gia một cách không chính thức vào việc tạo ra nó, thảo luận và củng cố sự hiểu biết về các giải pháp kỹ thuật chính. Tuy nhiên, việc sử dụng rộng rãi phương pháp luận này và tuân thủ các khuyến nghị của nó trong việc phát triển các IC tiếp xúc là khá hiếm, vì với việc phát triển thủ công (thủ công) thì điều đó gần như là không thể. Điều này đã góp phần vào sự xuất hiện của một loại phần mềm và phần cứng đặc biệt - CASE-các công cụ thực hiện công nghệ CASE để tạo và duy trì IS.

Cần phải hiểu rằng việc sử dụng thành công các công cụ CASE là không thể nếu không hiểu công nghệ cơ bản mà các công cụ này dựa trên đó. Tự bản thân, các công cụ phần mềm CASE là công cụ để tự động hóa các quy trình thiết kế và bảo trì hệ thống thông tin. Không thể sử dụng CASE-tools mà không hiểu phương pháp thiết kế IS.

1.3.1. Yêu cầu chung đối với phương pháp luận và công nghệ

Phương pháp luận, công nghệ và công cụ thiết kế (CASE-tools) tạo thành cơ sở cho việc thiết kế bất kỳ IS nào. Phương pháp luận được thực hiện thông qua các công nghệ cụ thể và các tiêu chuẩn, phương pháp luận và công cụ hỗ trợ của chúng để đảm bảo việc thực hiện các quá trình vòng đời.

Công nghệ thiết kế được định nghĩa là sự kết hợp của ba thành phần:

• một quy trình từng bước xác định trình tự của các hoạt động thiết kế công nghệ (Hình 1.4);
• tiêu chí và quy tắc sử dụng để đánh giá kết quả của hoạt động công nghệ;
• ký hiệu (phương tiện đồ họa và văn bản) được sử dụng để mô tả hệ thống được thiết kế.

Lúa gạo. 1.4. Trình bày hoạt động thiết kế công nghệ

Chỉ dẫn công nghệ, là nội dung chính của công nghệ, phải bao gồm mô tả về trình tự của các thao tác công nghệ, các điều kiện, tùy thuộc vào việc thực hiện một thao tác nào đó hoặc một hoạt động khác và các mô tả về chính các hoạt động đó.

Thiết kế, phát triển và bảo trì công nghệ của IS phải đáp ứng các yêu cầu chung sau:

• công nghệ phải hỗ trợ vòng đời hoàn chỉnh của phần mềm;
• công nghệ phải đảm bảo đạt được các mục tiêu phát triển của IS với chất lượng nhất định và trong một thời gian xác định;
• công nghệ phải cung cấp khả năng thực hiện các dự án lớn dưới dạng hệ thống con (tức là khả năng phân tách dự án thành các bộ phận thành phần của nó, được phát triển bởi các nhóm người thực hiện với một số lượng hạn chế với sự tích hợp tiếp theo của các bộ phận thành phần). Kinh nghiệm phát triển IS lớn cho thấy, để nâng cao hiệu quả công việc, cần chia nhỏ dự án thành các hệ thống con riêng biệt được kết nối yếu về dữ liệu và chức năng. Việc triển khai các hệ thống con nên được thực hiện bởi các nhóm chuyên gia riêng biệt. Đồng thời, cần đảm bảo sự phối hợp duy trì một dự án chung và loại trừ sự trùng lặp về kết quả công việc của từng nhóm dự án, có thể phát sinh do sự hiện diện của các dữ liệu và chức năng chung;
• công nghệ phải cung cấp khả năng tiến hành công việc thiết kế các hệ thống con riêng lẻ trong các nhóm nhỏ (3-7 người). Điều này là do các nguyên tắc quản lý nhóm và tăng năng suất bằng cách giảm thiểu số lượng các mối quan hệ bên ngoài;
• công nghệ phải cung cấp thời gian tối thiểu để có được một vi mạch hoạt động được. Chúng tôi không nói về thời gian sẵn sàng của toàn bộ IS, mà là về thời gian triển khai các hệ thống con riêng lẻ. Việc triển khai toàn bộ IS trong thời gian ngắn có thể cần sự tham gia của một số lượng lớn các nhà phát triển, trong khi hiệu quả có thể thấp hơn so với khi các hệ thống con riêng lẻ được thực hiện trong thời gian ngắn hơn bởi một số lượng nhỏ các nhà phát triển. Thực tiễn cho thấy rằng ngay cả khi có một dự án đã hoàn thành đầy đủ, việc thực hiện vẫn tiến hành tuần tự thông qua các hệ thống con riêng lẻ;
• công nghệ phải cung cấp khả năng quản lý cấu hình của dự án, duy trì các phiên bản của dự án và các thành phần của nó, khả năng tự động phát hành tài liệu dự án và đồng bộ hóa các phiên bản của nó với các phiên bản của dự án;
• công nghệ phải đảm bảo tính độc lập của các quyết định thiết kế được đưa ra từ các phương tiện thực hiện IS (hệ thống quản lý cơ sở dữ liệu (DBMS), hệ điều hành, ngôn ngữ và hệ thống lập trình);
• công nghệ cần được hỗ trợ bởi một tập hợp các công cụ CASE được phối hợp để đảm bảo tự động hóa các quá trình được thực hiện ở tất cả các giai đoạn của vòng đời. Cách tiếp cận chung để đánh giá và lựa chọn các công cụ CASE được mô tả trong phần 4, các ví dụ về sự phức hợp của các công cụ CASE - trong tiểu mục 5.7.

Việc áp dụng thực tế bất kỳ công nghệ nào để thiết kế, phát triển và bảo trì IS trong một tổ chức cụ thể và một dự án cụ thể là không thể nếu không có sự phát triển của một số tiêu chuẩn (quy tắc, thỏa thuận) mà tất cả những người tham gia dự án phải tuân thủ. Các tiêu chuẩn này bao gồm những điều sau:

• tiêu chuẩn thiết kế;
• tiêu chuẩn thiết kế cho tài liệu thiết kế;
• tiêu chuẩn giao diện người dùng.

Tiêu chuẩn thiết kế cần thiết lập:

• một tập hợp các mô hình (sơ đồ) cần thiết ở mỗi giai đoạn thiết kế và mức độ chi tiết của chúng;
• quy tắc sửa chữa các quyết định thiết kế trên sơ đồ, bao gồm: quy tắc đặt tên đối tượng (bao gồm cả quy ước về thuật ngữ), tập hợp các thuộc tính cho tất cả các đối tượng và quy tắc điền chúng ở mỗi giai đoạn, quy tắc thiết kế sơ đồ, bao gồm các yêu cầu về hình dạng và kích thước của các đối tượng, v.v.;
• yêu cầu đối với cấu hình nơi làm việc của nhà phát triển, bao gồm cài đặt hệ điều hành, cài đặt công cụ CASE, cài đặt dự án chung, v.v.;
• cơ chế đảm bảo công việc chung trong một dự án, bao gồm: quy tắc tích hợp hệ thống con của dự án, quy tắc duy trì dự án ở trạng thái giống nhau cho tất cả các nhà phát triển (quy tắc trao đổi thông tin thiết kế, cơ chế sửa chữa các đối tượng chung, v.v.), quy tắc kiểm tra các giải pháp thiết kế về tính nhất quán, v.v. d.

Tiêu chuẩn cho việc thiết kế tài liệu dự án cần thiết lập:

• tính đầy đủ, thành phần và cấu trúc của tài liệu ở từng giai đoạn thiết kế;
• các yêu cầu đối với thiết kế của nó (bao gồm các yêu cầu về nội dung của các phần, tiểu mục, đoạn văn, bảng, v.v.),
• các quy tắc chuẩn bị, xem xét, điều phối và phê duyệt tài liệu, chỉ ra thời hạn cho từng giai đoạn;
• yêu cầu thiết lập hệ thống xuất bản được sử dụng như một công cụ chuẩn bị tài liệu tích hợp sẵn;
• yêu cầu thiết lập CASE-công cụ để đảm bảo việc chuẩn bị tài liệu phù hợp với các yêu cầu đã thiết lập.

Tiêu chuẩn giao diện người dùng phải nêu rõ:

• quy tắc thiết kế màn hình (phông chữ và bảng màu), thành phần và sắp xếp các cửa sổ và điều khiển;
• quy tắc sử dụng bàn phím và chuột;
• quy tắc định dạng văn bản trợ giúp;
• danh sách các thông điệp tiêu chuẩn;
• quy tắc xử lý phản ứng của người dùng.