48665 (588592), страница 8

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 8)

При работе с компонентами С++ Builder широко использует принцип повторного использования объектов. Компоненты являются экземплярами классов которые доступны с помощью палитры компонентов Component Palette. Что может быть проще при создании приложения чем просто опустить нужный компонент на форму, задав его свойства, затем определив обработчики событий. Именно при помощи компонентов формы выполняют те функции, которые заложены в них.

1. Технологическое обеспечение задачи

1. Организация технологии сбора, передачи, обработки и выдачи информации

Разработка сложных программных комплексов вызывает необходимость решения ряда организационных, технологических и технических проблем, связанных со значительной трудоемкостью разработки программ и сложностью выявления в них ошибок. Решение этих проблем возможно при внедрении любой технологии программирования, которая позволит повысить производительность труда программистов и надежность программ. Кроме того, внедряемая технология должна упростить планирование работ и организацию взаимодействия всех членов коллектива, позволить четко контролировать сроки выполнения каждого этапа разработки, оперативно доводить до исполнителей все изменения в общих концепциях на создаваемое программное изделие и изменения в соглашениях о связях между программой и внешней средой или между отдельными структурными элементами программы. Технология должна обеспечить простоту и однозначность прочтения всей документации.

Сокращение сроков и снижение трудоемкости внедрения программного изделия зависят от его надежности. Поэтому технология должна предусматривать организацию процессов верификации и тестирования алгоритмов и программ на стадии разработки, также подходы к отладке и испытаниям программы. Технология должна обеспечивать возможность достаточно простой модификации программ при их эксплуатации, что необходимо для устранения обнаруженных ошибок или для изменения функций программы.

Технология разработки сложных программных комплексов требует разбиения программного изделия на отдельные модули. При этом часто модули создаются независимо друг от друга разными программистами. Для объединения модулей в программный комплекс необходимо разработать правила вызова модулей и правила передачи параметров между отдельными модулями. Эти правила образуют внутри- программный интерфейс.

Внутрипрограммный интерфейс должен разрабатываться на начальном этапе проектирования программы. Разработка его включает:

• анализ обрабатываемой информации и выбор логической организации данных;

• выбор абстрактных структур данных для представления информации в соответствии с используемым языком программирования равной логической организацией данных;

• выбор физической организации данных;

• выбор структуры и способов взаимодействия отдельных программных модулей.

Разработка состава сложного программного изделия является одним из основных этапов создания программы, на котором в составе программы необходимо выделить отдельные модули, определить их функции, порядок вызова, правил взаимодействия и взаимоподчиненности. Разбиение программы на модули следует выполнять с учетом сложившегося представления об основных свойствах модулей :

• Модуль - независимая программа, которая может вызываться операционной системой или другим программным модулем. Ссылки на модуль выполняются по имени модуля.

• Модуль должен возвращать управление тому модулю, который его вызвал.

• Модуль должен иметь один вход и один выход. Единственность входа гарантирует замкнутость модуля, однозначность его вызова и существенно облегчает отладку и сопровождение программы.

• Модуль должен иметь ограниченные размеры. Это требование определяется тем, что каждый модуль организует отдельную, сравнительно небольшую функцию. Кроме того, текст модуля должен быть обозримым для облегчения его понимания и сопровождения.

• Работа модуля не должна зависеть от его предыдущих вызовов.

После того, как определена структура программы и основные типы передаваемых данных, устанавливаются соглашения о связях между модулями. Соглашения включают в себя правила вызова отдельных модулей, правила передачи параметров и правила связи разрабатываемого программного изделия с операционной системой.

Правильный выбор функций и последующее распределение их между модулями с учетом логических связей является основной задачей при проектировании сложных программ.

Наиболее широко распространенным подходом к проектированию является нисходящее программирование.

Этот подход интуитивно привлекателен, за последние несколько лет он подвергался неоднократному обсуждению в литературе. Нисходящее проектирование известно и под другими названиями, например "конструктивное программирование", "программирование пошаговым совершенствованием" и "иерархическое проектирование".

Нисходящее программирование основывается на последовательной декомпозиции решаемой задачи на некоторые абстрактные функции с последующим уточнением каждой из них. Таким образом, для сложной программы получается иерархическая система программных модулей.

На каждом шаге производится последовательное уточнение функций, реализуемых модулями.

Эта детализация выполняется до тех пор, пока не будет достигнуто элементарное представление операции при реализации каждой из функций.

Нисходящее программирование позволяет создавать достаточно сложные программы.

При этом требования к квалификации программистов, реализующих отдельные модули, могут быть снижены.

1. Схемы технологического процесса сбора, передачи, обработки и выдачи информации

В данном разделе представлены функционально-технологические схемы решения задачи.

В первую очередь рассмотрим задачу ведения справочников, назовем ее А1. Для ее реализации менеджер по ведению каталогов сортирует данные, а затем вводит данные в соответствующие таблицы. Задача ввода данных может быть разбита на несколько этапов. Функционально-технологическая схема решения задачи А1 приведена на рисунке 2.13.

Рисунок 2.2. Функционально-технологическая схема задачи А1 «Ведение справочников»

Для каждого выделенного модуля разработана функционально-технологическая схема и детальный алгоритм ее кодирования. Блок-схема задачи А1 приведена на рисунке 2.14, а функционально-технологические схемы всех модулей задачи А1 – на рисунке 2.15.

Рисунок 2.3. схема решения задачи А1 «Ведение справочников»

Рисунок 2.4. Функционально-технологические схемы модулей задачи А1

Опишем подробнее полученные схемы.

Для модуля А1.1:

Процесс: Проверка и внесение данных о товаре.

Вход: информация о товаре.

Выход: сформированные данные о товаре в БД

Алгоритм:

• Проверка наличия данных о товаре в БД

• Если данные отсутствуют, то внести новую запись в БД

• Вывести данные о товаре на экран.

Для модуля А 1.2:

Процесс: Проверка и внесение данных о клиенте.

Вход: информация о клиенте.

Выход: сформированные данные о клиенте в БД

Алгоритм:

• Проверка наличия данных о клиенте в БД

• Если данные отсутствуют, то внести новую запись в БД

• Вывести данные о клиенте на экран.

Для модуля А 1.3:

Процесс: Проверка и внесение данных о свойстве товара.

Вход: информация о свойстве товаре.

Выход: сформированные данные о свойстве товара в БД

Алгоритм:

• Проверка наличия данных о свойстве товаре в БД

• Если данные отсутствуют, то внести новую запись в БД

• Вывести данные о свойстве товара на экран.

Для модуля А 1.4:

Процесс: Проверка и внесение данных о пользователе.

Вход: информация о пользователе.

Выход: сформированные данные о пользователе в БД

Алгоритм:

• Проверка наличия данных о пользователе в БД

• Если данные отсутствуют, то внести новую запись в БД

• Вывести данные о пользователе на экран.

Для модуля А 1.5:

Процесс: Проверка и внесение данных о проектах.

Вход: информация о проекте.

Выход: сформированные данные о проекте в БД

Алгоритм:

• Проверка наличия данных о проекте в БД

• Если данные отсутствуют, то внести новую запись в БД

• Вывести данные проекте на экран.

Для модуля А 1.6:

Процесс: Проверка и внесение данных о подразделении.

Вход: информация о подразделении.

Выход: сформированные данные о подразделении в БД

Алгоритм:

• Проверка наличия данных о подразделении в БД

• Если данные отсутствуют, то внести новую запись в БД

• Вывести данные о подразделении на экран.

Для модуля А 1.7:

Процесс: Проверка и внесение данных о производителях.

Вход: информация о производителе.

Выход: сформированные данные о производителе в БД

Алгоритм:

• Проверка наличия данных о производителе в БД

• Если данные отсутствуют, то внести новую запись в БД

• Вывести данные о производителе на экран.

Далее рассмотрим задачу внесения в систему документов, назовем ее Б1. Для решения этой задачи оператор группы оформления документов сортирует входящие бумажные документы, обрабатывает их и вносит в систему, в результате чего изменяются записи в таблице остатков и журнале документов. Функционально-технологическая схема задачи Б1 представлена на рисунке 2.16.

Рисунок 2.5. Функционально-технологическая схема задачи Б1 «Введение документов».

Для каждого выделенного модуля разработана функционально-технологическая схема и детальный алгоритм ее кодирования. Блок-схема задачи Б1 приведена на рисунке 2.17, а функционально-технологические схемы всех модулей задачи Б1 – на рисунке 2.18.

Рисунок 2.6. Блок схема решения задачи Б1 «Введение документов»

Рисунок 2.7. Функционально-технологические схемы модулей задачи Б1

Далее рассмотрим задачу получения отчетов, назовем ее В1. Для решения этой задачи пользователь программы выбирает нужный вид отчета, в результате чего формируется экранная форма выбранного вида отчета Функционально-технологическая схема задачи В1 представлена на рисунке 2.19.

Рисунок 2.8. Функционально-технологическая схема задачи В1 «Формирование отчетов»

Блок-схема задачи В1 приведена на рисунке 2.20, а функционально-технологические схемы всех модулей задачи В1 – на рисунке 2.21

Рисунок 2.9. Блок-схема задачи В1

Характеристики

Список файлов ВКР