Разработка приложения для учета и анализа электропотребления в системе АИСС КУЭ

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

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

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

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

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

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

Таким образом, объектом данного дипломного проектирования являются изучение энергетической отрасли, а предметом – алгоритмы расчета и прогнозирования энергопотребления.

Целью этого дипломного проекта является разработка приложения для расчета и прогнозирования энергопотребления в системе АИИС КУЭ.

Для достижения данной цели необходимо решить следующие задачи:

Провести сравнительный анализ существующих решений
Проанализировать предметную область
Собрать требования к системе
Реализовать информационную систему
Провести тестирование продукта

Глава 1. Анализ предметной области и определение требований к разрабатываемой системе

1.1. Описание структуры предприятия

1.1.1. Сведения о предприятии

ОАО «Энергоучет» создано в ноябре 2000 года. Производственные мощности предприятия в настоящее размещаются на площади более 2000 квадратных метров (объединенных в локальную сеть), оборудованы ремонтным и метрологическим оборудованием, вычислительной и оргтехникой, имеется электротехническая лаборатория и свыше 20 единиц автомобильной техники. Организационная структура предприятия представлена на Рисунке 1.

Основными направлениями деятельности ОАО «Энергоучет» являются:

создание автоматизированных информационно-измерительных систем коммерческого учета электроэнергии (АИИС КУЭ);
установка и замена приборов и систем учета электроэнергии на объектах электроэнергетики и у потребителей (абонентов);
ремонт однофазных и трехфазных электросчетчиков (в том числе электронных);
оказание других сервисных и метрологических услуг в части технического обеспечения учета количества электроэнергии и мощности.

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

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

Для реализации производственных задач ОАО «Энергоучет» обладает уникальным для ской области парком метрологического, испытательного, измерительного и необходимого вспомогательного оборудования.

Актуализированная нормативная база, аттестованные методики выполнения измерений (МВИ), стандарты ОАО «Энергоучет» (СТП) обеспечивают реализацию всех необходимых требований к качеству, составу и технологии выполняемых работ.

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

По одному из направлений своей производственной деятельности — за последние два года ОАО «Энергоучет» по договорам генподряда выполнил работы по созданию в ОАО «энерго» автоматизированных информационно-измерительных систем коммерческого учета электроэнергии (АИИС КУЭ) на ИГРЭС, КТЭЦ, ОТЭЦ-1 и СТЭЦ, а также на более пятнадцати подстанциях 110 и 220 кВ с выполнением полного цикла работ «под ключ» (комплексная ревизия узлов учета электроэнергии, предпроектное обследование, проектирование, монтаж, метрологическое обеспечение, пуск в эксплуатацию с последующим сервисным техническим и программным сопровождением измерительных систем).

1.1.2. Изучение архитектуры и работы программного обеспечения

В данном разделе содержится обзорная и ссылочная информация по программному обеспечению ПТК «ЭКОМ» (далее по тексту ПО ПТК «ЭКОМ»), в которое будет внедрено разрабатываемое программное средство.

ПО ПТК – это комплекс программных приложений, предназначенный для построения различного типа автоматизированных систем: АСКУЭ, АСДУ и АСУ ТП. В состав ПО ПТК входят приложения верхнего уровня, позволяющие решать как общие задачи по построению АРМ операторов систем АСДУ, АСУ ТП, так и специализированные задачи для систем АСКУЭ. Помимо УСПД «ЭКОМ-3000», входящих в ПТК «ЭКОМ», в систему на нижнем уровне могут быть интегрированы почти любые интеллектуальные устройства.

АСКУЭ – многоуровневая распределенная система сбора и обработки информации. Первый уровень состоит из счетчиков и первичных преобразователей импульсов.

Показания счетчиков поступают в систему двумя путями. Первый – энергия, преобразованная в импульсы, с платы реле счетчика Альфа поступает на вход УСПД ЭКОМ-3000. Второй – энергия, накопленная за получасовые интервалы, накапливается в энергонезависимой памяти счетчиков Альфа. Эти значения раз в сутки считываются по кодовому каналу (ИРПС) на УСПД. На УСПД информация сохраняется в локальных энергонезависимых архивах. Оперативная информация записывается с частотой 3 минуты, основная – 30 мин. Таким образом, в УСПД архивируется три типа данных: 3-х мин импульсы, 30-ти мин импульсы и 30-ти мин архивы счетчиков. Глубина хранения архивов настраивается.

Архивы, накопленные в УСПД, передаются на SQL-сервер программой Сервер опроса (Сканер3000). «Сервер опроса» является средством доступа к данным устройств системы в ПО ПТК «ЭКОМ». «Сервер опроса» является приложением, обеспечивающим опрос и передачу данных в интеллектуальные устройства нижнего уровня. Для хранения полученной информации и предоставления ее другим приложениям верхнего уровня данные записываются в БД SQL-сервера.

Функциональные возможности:

сбор данных с устройств;
УСПД «ЭКОМ-3000»;
ModbusRTU-совместимых контроллеров;
SoftBasic-контроллеров;
электросчетчиков типа СЭТ-4ТМ.01(02);
электросчетчиков типа EAxxxxx (ЕвроАльфа);
теплосчетчиков типа ТСР фирмы Взлет;
расходомеров-счетчиков типа УРСВ-010М;
запись полученных данных в БД;
коррекция времени УСПД по локальному времени;
коррекция локального времени по времени SQL-сервера;
выдача по требованию команд управления в устройства ЭКОМ-3000;
ModbusRTU-совместимые контроллеры и SoftBasic-контроллеры;
протоколирование событий;
хронометраж отдельных стадий и процесса в целом.

Программа рассчитана на постоянную, круглосуточную работу. На сервере постоянно хранится дата и время последнего опроса каждого УСПД. Связь УСПД – Сканер3000 – SQL-сервер может быть нарушена без потери данных на время, в течение которого данные хранятся в УСПД (глубина архивирования). После восстановления связи Сканер считывает данные из УСПД, начиная со времени последнего успешного опроса.

Сканер3000 – гибкая, настраиваемая программа, реализующая различные способы чтения данных.

На SQL-сервере располагается база данных АСКУЭ. В ней содержится информация о системе в целом, об объектах, линиях, счетчиках и УСПД, входящих в состав системы.

Кроме того, здесь хранятся архивы по электроэнергии. Трехминутный архив содержит информацию за последний месяц. 30-ти минутный архив содержит основную (коммерческую) информацию и хранится вечно (записи не удаляются).

Пользователи получают информацию с помощью АРМа «Электроэнергия». Вход в АРМ защищен паролем. Права и перечень доступных объектов определяются именем пользователя и паролем. Существует несколько типов АРМов: диспетчера, энергетика, инженера, экономиста, метролога, программиста. Различаются АРМы по количеству предоставляемых функций и правам на редактирование. Максимальные права у АРМа программиста. Он имеет доступ ко всем функциям системы, кроме метрологических испытаний, доступ к которым имеет только АРМ метролога и редактирования коммерческих объектов, для этого необходима дополнительная роль «энергонадзор».

Кроме типа АРМа, каждому пользователю определяется набор доступных объектов. Таким образом, с любого рабочего места системы, можно получить информацию, объем которой определяется именем и паролем пользователя, вошедшего в систему. Все основные действия (вход, выход из системы, редактирование объектов) заносятся в протокол АСКУЭ. Все действия по созданию имен, паролей, списков доступных объектов производятся администратором АСКУЭ с помощью программы AdCenter – Консоль администратора АСКУЭ.

В состав ПО ПТК входят приложения, имеющие различное функциональное назначение. Полный состав ПО ПТК «ЭКОМ» представлен на Рисунке 2. Пунктиром на рисунке отмечено программное обеспечение, не входящее в состав ПТК «ЭКОМ».

Все программы, входящие в состав ПО ПТК «ЭКОМ», можно условно разделить на приложения «верхнего» и «нижнего» уровня в соответствии с архитектурой построения системы в целом.

К «нижнему» уровню относится ПО, устанавливаемое на интеллектуальных устройствах «нижнего» уровня системы – встроенное ПО. Непосредственно в состав ПО ПТК «ЭКОМ» на «нижнем» уровне входит только ПО «ЭКОМ-3000».

ПО «верхнего» уровня – это ПО, устанавливаемое на РС системы. К ПО «верхнего» уровня в первую очередь относится набор инструментальных средств визуализации параметров работы системы, т.е. приложений для создания АРМ операторов и других пользователей системы:

«Control Age»;
АРМ «Электроэнергия».

Доступ приложений к данным интеллектуальных устройств «нижнего» уровня осуществляется через «Сервер опроса», который выполняет обмен данными с этими устройствами.

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

В составе ПО ПТК входят также служебные программы, позволяющие производить настройку работы УСПД «ЭКОМ-3000» и тестирование качества обмена данными. К таким приложениям относятся:

Конфигуратор-3000;
Архив.

Программы «верхнего» уровня являются приложениями-клиентами Microsoft SQL Server (далее MS SQL Server). Использование MS SQL Server, позволяет организовать работу системы по технологии «Client/Server». Технология «Client/Server» дает возможность строить распределенные масштабируемые системы на базе ПТК «ЭКОМ». На «верхнем» уровне системы может быть установлено теоретически неограниченное количество различных программ или копий одной и той же программы на отдельных РС. При этом функциональной зависимости между отдельными приложениями при использовании данной технологии нет, а существует только взаимосвязь, определяемая использованием одного набора данных, расположенного в БД ПТК «ЭКОМ» на MS SQL Server.

Под БД ПТК «ЭКОМ», представлено на Рисунке 3, понимается не только специфический набор таблиц, но и набор хранимых процедур по обработке данных, используемых программами верхнего уровня ПТК «ЭКОМ», заданий для MS SQL Server Agent по «очистке» устаревших данных и экспорту основных данных. Перечисленные объекты также являются программным обеспечением ПТК «ЭКОМ».

На данном рисунке:

КА – Консоль администратора;
СО – Сервер опроса;
CA – Control Age;
ЭЭ – Электроэнергия.

Определение информационных потоков предприятия

На Рисунке 4 приведены информационные потоки между подразделениями предприятия.

Приведены следующие условные обозначения:

1 – получение распоряжений на внедрение АИИС КУЭ на новых объектах, доведение распоряжений, инструкций, приказов от выше стоящих инстанций;

2 – доклад о выполнении работ, по построению АИИС КУЭ на новых объектах с соблюдением графика и условий договора с предприятиями;

3 – дача распоряжений и указаний на поиск и разработку новых объектов для построения АИИС КУЭ;

4 – доклад о заключении договоров на построение АИИС КУЭ на новых объектах;

5 – отчет о выполнении распоряжений, инструкций, приказов от выше стоящих инстанций;

6 – получение устных распоряжений, инструкций, приказов от выше стоящих инстанций;

7 – дача распоряжений на проведение финансовых операций;

8 – отчет обо всех финансовых операциях и финансовом положении предприятия;

9 – дача распоряжений на подготовку документов для участия в тендерах, на составление планов поставки оборудования, на поиск экономически выгодных поставщиков, на составление графика объема работ для предприятия на год и на перспективу;

10 – отчет о выполнении распоряжений по п.9;

11 – дача указаний на составление договоров с предприятиями, юридические консультации сотрудникам предприятия, контроль по соблюдению прав работников предприятия;

12 – доклад обо всех юридических операциях;

13 – дача распоряжений о приеме граждан на работу, на составление руководящих и организационных документов;

14 – доклад о выполнении указаний по п.13;

15 – работа с предприятиями, банками, налоговыми органами;

16 – получение накладных, счетов, актов выполненных работ, проводка всех финансовых документов;

17 – предложения по освоению новых объектов;

18 – предложения о сотрудничестве от внешних организаций;

19 – ведение дел в судах, работа с предприятиями по договорам, нотариальная заверка документов;

20 – получение договоров от предприятий;

21 – переписка с военкоматами, пенсионным отделом, отделом социальной защиты, биржей труда, налоговыми органами;

22 – работа с военкоматами, пенсионным отделом, отделом социальной защиты, биржей труда, налоговыми органами;

23 – заключение договоров с предприятиями, работа с заводами изготовителями техники для АИИС КУЭ;

24 – ведение переписки с предприятиями, заводами изготовителями техники АИИС КУЭ;

25 – дача указаний на внеплановые инструктажи по ТБ, контроль ведения журналов по ТБ;

26 – доклад о проведении инструктажа и о нарушениях на предприятии по ТБ;

27 – проведение плановых и внеплановых инструктажей, доведение информации обо всех случаях нарушения ТБ на объектах энергетики;

28 – согласование вопросов по строительству АИИС КУЭ;

29 – получение писем от предприятий, включенных в систему АИИС КУЭ, о введении;

30 – дача распоряжений по подготовке документов, к сдаче в опытную и промышленную эксплуатацию АИИС КУЭ на вновь вводимых объектах;

31 – доклад о подготовке документов, к сдаче в опытную и промышленную эксплуатацию АИИС КУЭ на вновь вводимых объектах;

32 – дача распоряжений на внедрение системы АИИС КУЭ на новом объекте, доведение распоряжений, инструкций, приказов от выше стоящих инстанций;

33 – доклад о проведении предпроектного обследования, составлению проекта, о выполнении монтажных и пуско-наладочных работах на вновь вводимых объектах;

34 – дача указаний на предпроектное обследование объектов, составления проекта АИИС КУЭ;

35 – отчет о выполнении предпроектного обследования объектов, составления проекта АИИС КУЭ;

36 – доведение информации обо всех изменениях в наименовании учетов, сменах коэффициентов трансформации на присоединениях, временном отсутствии каналов передачи информации;

37 – ежедневный доклад о работе всей системы АИИС КУЭ;

38 – дача распоряжения на проведение монтажных работ на вновь вводимом объекте АИИС КУЭ;

39 – доклад о завершении монтажных работ на объектах АИИС КУЭ;

40 – доклад о завершении пуско-наладки объектов АИИС КУЭ, об устранении неисправности во всей системе АИИС КУЭ в рамках сервисного обслуживания;

41 – дача распоряжения на проведение пуско-наладки на вновь вводимом объекте;

42 – доведение информации обо всех нарушениях в работе системы АИИС КУЭ;

43 – доведение информации о пуско-наладке объектов АИИС КУЭ, о новых номерах присоединений, об устранении неисправности в системе АИИС КУЭ;

44 – доведение информации обо всех нарушения в производстве монтажа, с контролем прохождения данных от всех точек учета электроэнергии до главного сервера центра сбора информации;

45 – доклад об окончании монтажных работ и готовности к пуско-наладке системы АИИС КУЭ;

46 – доведение информации об изменении в проекте при проведении монтажных работ;

47 – получение проекта на выполнение монтажных работ по построению АИИС КУЭ;

48 – сдача проектной документации в архив ПТО;

49 – запрос на предоставление проектной документации на вновь вводимые объекты АИИС КУЭ;

50 – представляет проект для проведения пуско-наладки объектов АИИС КУЭ;

51 – дает предложения об использовании оборудования при составлении проектов на построение АИИС КУЭ;

52 – дача распоряжений на использование и распределение транспорта;

53 – доклад о готовности транспорта, подача заявок на проведение ремонта транспорта и приобретение запасных частей.

1.3. Обзор существующих аналогов

1.3.1. АРМ «Control Age»

АРМ «Control Age» является инструментальным средством, предназначенным для визуализации контролируемых технологических параметров и оперативного диспетчерского управления на верхнем уровне АСУ ТП, АСДУ, а также для контроля потребления энергоресурсов в системах учета. АРМ «Control Age» объединяет средства разработки и просмотра графических мнемосхем автоматизированных рабочих мест оператора (АРМ).

АРМ «Control Age» обладает следующими основными характеристиками:

инструменты создания экранных форм и динамических элементов отображения;
динамизация элементов отображения со временем обновления графической информации;
средства импорта графических метафайлов (EMF, WMF) и растровых изображений (BMP, JPG, GIF, TIFF и др.);
встроенный редактор выражений для выполнения математических, функциональных и других операций над данными;
возможность просмотра графиков текущих и архивных данных;
встроенный генератор отчетов с возможностью экспорта данных в MS Excel;
скриптоязык для дополнительного управления отображением информации на мнемосхемах;
встроенный редактор и обработчик событий, позволяющий контролировать возникновение различных ситуаций в системе, производить текстовое и звуковое оповещение оперативного персонала о возникновении событий, прием подтверждений восприятия (квитирования) информации о возникновении событий и регистрация событий и квитирования в базе данных.

Уровень подготовки пользователя:

для работы с АРМом пользователь должен обладать навыками работы с ПЭВМ типа IBM PC в операционной среде Windows NT/2000/XP;
каждый пользователь в соответствии со своими правами должен обладать необходимыми знаниями в предметной области для корректной работы с предоставляемой информацией. Имя и пароль определяют права и объем информации, доступной пользователю, персональные настройки его рабочего пространства. Окно входа в систему показано на Рисунке 5;
для просмотра и печати выходных форм АРМа необходимо обладать навыками работы с Microsoft Office и уметь обращаться с принтером.

Условия работы:

для работы АРМа необходим персональный компьютер типа IBM PC (Pentium III 128М RAM);
компьютер должен нормально функционировать, согласно сопроводительной документации. Компьютер должен иметь сетевой доступ к серверу ПТК ЭКОМ;
на компьютере должны быть установлены:
операционная система Windows NT/2000/XP;
MS Office 2000 или выше;
Клиент MS SQL

1.3.2. АРМ «Электроэнергия»

АРМ «Электроэнергия» – автоматизированная система контроля и учета электроэнергии на базе ПТК ЭКОМ (далее АСКУЭ, система).

АРМ «Электроэнергия» предназначен для работы в составе АСКУЭ. АРМ «Электроэнергия» является инструментальным средством, предназначенным для отображения, ввода, редактирования и печати данных АСКУЭ и обеспечивает следующие основные возможности:

расход и потребление количества электрической энергии с использованием счетчиков со стандартным телеметрическим и кодовым выходом;
перечень счетчиков, входящих в состав АСКУЭ;
формирование линий и объектов учета;
нормируемые показатели по всем объектам системы;
графическое представление информации с возможностью ранжирования объектов по различным признакам;
сводная информация за любой период с дискретностью 3 мин, 30 мин, сутки, месяц;
проведение метрологических испытаний (АРМ метролога);
конфигурирование системы (АРМ программиста).

Каждому пользователю АСКУЭ предоставляется список доступных объектов. По каждому из объектов определяется два уровня доступа: просмотр и редактирование (запись). Редактировать список доступных объектов можно только в режиме корректирования. Список объектов, доступных пользователям, и уровень доступа к ним (представлены на Рисунке 6) определяются административно.

Уровень подготовки пользователя:

для работы с АРМом пользователь должен обладать навыками работы с ПЭВМ типа IBM PC в операционной среде Windows 95/98/2000/NT;
каждый пользователь в соответствии со своими правами должен обладать необходимыми знаниями в предметной области для корректной работы с предоставляемой информацией;
для просмотра и печати выходных форм АРМа необходимо обладать навыками работы с Microsoft Office и уметь обращаться с принтером.
для работы с АРМом необходимо изучить руководство. Перечень рекомендуемой документации.

При работе с АРМом рекомендуется пользоваться следующими документами:

Устройство сбора и передачи данных ЭКОМ-3000, ПТК ЭКОМ;
Microsoft Office 97/2000. Руководство пользователя.

Вид главного окна АРМа представлен на Рисунке 7.

Условия работы:

для работы АРМа необходим персональный компьютер типа IBM PC (Pentium 133,ОЗУ 16Мб, НЖМД 600Мб);
компьютер должен нормально функционировать, согласно сопроводительной документации. Компьютер должен иметь сетевой доступ к серверу АСКУЭ;
на компьютере должны быть установлены:
операционная система Windows 95/98/2000/NT;
программное обеспечение BDE v.5.01;
программное обеспечение «Клиент MS SQL0/2000.»;
Microsoft Office 97/2000.

1.4. Постановка задачи

Основной задачей стала необходимость разработать программное средство для расчета и прогнозирования энергопотребления в системе “АИИС КУЭ” для отдела информационных технологий ООО «Энергоучет».

В программном средстве ведутся данные об энергообъектах, происходит автоматизированная обработка данных об энергопотреблении, а также анализ результатов обработки.

Программа выполняет следующие функции:

ведение данных об энергопотреблении на объектах;
расчет недостающих значений по энергопотреблению;
добавление и обновление данных по энергопотреблению;
определение срока отсутствия связи со счетчиками на объектах.

Разработанное программное средство должно:

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

1.5. Вывод

В первом подразделе была рассмотрена структура предприятия и проанализирована работа подразделения АСКУЭ ОАО «Энергоучет».

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

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

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

Глава 2. Проектирование и реализация программного комплекса

2.1. Обоснование выбора архитектуры программного средства

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

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

Технология программирования – совокупность методов и средств, используемых в процессе проектирования программного обеспечения (ПО).

Каждая технология имеет технологический инструмент, который включает:

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

Рассмотрим существующие виды технологий разработки ПО:

технология «стихийного» программирования;
технология структурного программирования;
технология объектно-ориентированного программирования (ООП);
компонентные технологии;
Case – технологии.

Стихийное и структурное программирование уже является устаревшей методикой и на практике почти не применяется (структурное частично применяется).

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

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

В Case средах отличительной особенностью является наличие автоматизированной разработки и сопровождения ПО. В современных условиях создание сложных программных приложений невозможно без использования систем автоматизированного конструирования ПО (CASE-систем). CASE-системы существенно сокращают сроки и затраты разработки, оказывая помощь инженеру в проведении рутинных операций, облегчая его работу на самых разных этапах жизненного цикла разработки.

Наиболее распространенными и применимыми являются: метод восходящей разработки и метод нисходящей разработки ПС.

Метод восходящей разработки заключается в следующем. Сначала строится модульная структура программы в виде дерева. Затем поочередно программируются модули программы, начиная с модулей самого нижнего уровня (листья дерева модульной структуры программы), в таком порядке, чтобы для каждого программируемого модуля были уже запрограммированы все модули, к которым он может обращаться. После того, как все модули программы запрограммированы, производится их поочередное тестирование и отладка в принципе в таком же (восходящем) порядке, в каком велось и программирование. Такой порядок разработки программы на первый взгляд кажется вполне естественным: каждый модуль при программировании выражается через уже запрограммированные непосредственно подчиненные модули, а при тестировании использует уже отлаженные модули. Однако, современная технология не рекомендует такой порядок разработки программы. Во-первых, для программирования какого-либо модуля совсем не требуется наличия текстов используемых им модулей − для этого достаточно, чтобы каждый используемый модуль был лишь специфицирован (в объеме, позволяющем построить правильное обращение к нему), а для тестирования его возможно (и даже, как мы покажем ниже, полезно) используемые модули заменять их имитаторами (заглушками, драйверами). Во-вторых, каждая программа в какой-то степени подчиняется некоторым внутренним для нее, но глобальным для ее модулей соображениям (принципам реализации, предположениям, структурам данных и т.п.), что определяет ее концептуальную целостность и формируется в процессе ее разработки. При восходящей разработке эта глобальная информация для модулей нижних уровней еще не ясна в полном объеме, поэтому очень часто приходится их перепрограммировать, когда при программировании других модулей производится существенное уточнение этой глобальной информации (например, изменяется глобальная структура данных). В-третьих, при восходящем тестировании для каждого модуля (кроме головного) приходится создавать ведущую программу (модуль), которая должна подготовить для тестируемого модуля необходимое состояние информационной среды и произвести требуемое обращение к нему. Это приводит к большому объему «отладочного» программирования и в то же время не дает никакой гарантии, что тестирование модулей производилось именно в тех условиях, в которых они будут выполняться в рабочей программе.

Метод нисходящей разработки заключается в следующем. Как и в предыдущем методе сначала строится модульная структура программы в виде дерева. Затем поочередно программируются модули программы, начиная с модуля самого верхнего уровня (головного), переходя к программированию какого-либо другого модуля только в том случае, если уже запрограммирован модуль, который к нему обращается. После того, как все модули программы запрограммированы, производится их поочередное тестирование и отладка в таком же (нисходящем) порядке. При этом первым тестируется головной модуль программы, который представляет всю тестируемую программу.

При этом те модули, к которым может обращаться головной, заменяются их имитаторами (так называемыми заглушками). Каждый имитатор модуля представляется весьма простым программным фрагментом, который, в основном, сигнализирует о самом факте обращения к имитируемому модулю, производит необходимую для правильной работы программы обработку значений его входных параметров (иногда с их распечаткой) и выдает, если это необходимо, заранее запасенный подходящий результат. После завершения тестирования и отладки головного и любого последующего модуля производится переход к тестированию одного из модулей, которые в данный момент представлены имитаторами, если таковые имеются. Для этого имитатор выбранного для тестирования модуля заменяется самим этим модулем и, кроме того, добавляются имитаторы тех модулей, к которым может обращаться выбранный для тестирования модуль. При этом каждый такой модуль будет тестироваться при «естественных» состояниях информационной среды, возникающих к моменту обращения к этому модулю при выполнении тестируемой программы. Таким образом, большой объем «отладочного» программирования при восходящем тестировании заменяется программированием достаточно простых имитаторов используемых в программе модулей. Кроме того, имитаторы удобно использовать для того, чтобы подыгрывать процессу подбора тестов путем задания нужных результатов, выдаваемых имитаторами. При таком порядке разработки программы вся необходимая глобальная информация формируется своевременно, т.е. ликвидируется весьма неприятный источник просчетов при программировании модулей. Некоторым недостатком нисходящей разработки, приводящим к определенным затруднениям при ее применении, является необходимость абстрагироваться от базовых возможностей используемого языка программирования, выдумывая абстрактные операции, которые позже нужно будет реализовать с помощью выделенных в программе модулей. Однако способность к таким абстракциям представляется необходимым условием разработки больших программных средств, поэтому ее нужно развивать.

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

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

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

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

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

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

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

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

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

Отладка ПС − это деятельность, направленная на обнаружение и исправление ошибок в ПС с использованием процессов выполнения его программ. Тестирование ПС − это процесс выполнения его программ на некотором наборе данных, для которого заранее известен результат применения или известны правила поведения этих программ. Указанный набор данных называется тестовым или просто тестом. Таким образом, отладку можно представить в виде многократного повторения трех процессов: тестирования, в результате которого может быть констатировано наличие в ПС ошибки, поиска места ошибки в программах и документации ПС и редактирования программ и документации с целью устранения обнаруженной ошибки. Другими словами: Отладка = Тестирование + Поиск ошибок + Редактирование.

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

Тестирование – процесс многократного повторения программы с целью обнаружения ошибок. Тестирование – составная часть отладки.

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

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

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

Существуют следующие методы тестирования ПС:

статическое тестирование – ручная проверка программы за столом;
детерминированное тестирование – при различных комбинациях исходных данных;
стохастическое – исходные данные выбираются произвольно, на выходе определяется качественное совпадение результатов или примерная оценка.

Имеется два подхода к тестированию:

структурное тестирование – метод «белого ящика», тестируется логика программы, внутренняя структура программы;
функциональное тестирование – метод «черного ящика»- тестируется спецификация, т.е. вход/выход без учета знаний о ее структуре.

В нашей стране различаются два основных вида отладки (включая тестирование): автономную и комплексную отладку ПС.

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

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

При разработке данного программного средства будут использованы нисходящий метод проектирования БД и конструктивный подход проектирования ПС, а также объектно-ориентированная технология программирования. Осталось разобраться с выбором конкретной модели баз данных.

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

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

Рассмотрим четыре модели баз данных:

автономные;
файл-серверные;
клиент/сервер;
многоярусные.

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

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

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

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

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

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

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

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

Спецификой архитектуры клиент/сервер является использование языка запросов SQL.

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

В базе данных клиент/сервер возникает дополнительная проблема – спроектировать приложение так, чтобы оно максимально использовало возможности сервера и минимально нагружало сеть, передавая через нее только минимум информации.

Многоярусные базы данных это сравнительно новый и многообещающий путь обработки данных в сети. Иногда этот способ организации баз данных называется multitier – многонитевые. В этом термине под нитью понимается один из множества потоков данных, обменивающихся одновременно с базой данных.

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

Была разработана архитектура программной системы, представленная на Рисунке 8:

2.2. Выбор и обоснование методов проектирования и программирования

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

Всегда, когда возникает потребность манипулировать большими массивами данных, используются базы данных. Работа с базами данных в Delphi – это очень обширная тема. Создают базы данных и обрабатывают запросы к ним системы управления базами данных – СУБД. Известно множество СУБД, различающихся своими возможностями и конкурирующих друг с другом: Paradox, dBase, Microsoft SQL Server, MySQL, Microsoft Access, FoxPro, Oracle, InterBase, Sybase и много других.

Выбор системы управления баз данных (СУБД) представляет собой сложную многопараметрическую задачу и является одним из важных этапов при разработке приложений баз данных. Выбранный программный продукт должен удовлетворять как текущим, так и будущим потребностям предприятия, при этом следует учитывать финансовые затраты на приобретение необходимого оборудования, самой системы, разработку необходимого программного обеспечения на ее основе, а также обучение персонала. Кроме того, необходимо убедиться, что новая СУБД способна принести предприятию реальные выгоды.

В данной работе по результатам анализа доступных источников, делается попытка сформулировать требования или, иными словами, критерии при выборе СУБД, приводится классификация требований/критериев. Очевидно, наиболее простой подход при выборе СУБД основан на оценке того, в какой мере существующие системы удовлетворяют основным требованиям создаваемого проекта информационной системы. Более сложным и дорогостоящим вариантом

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

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

Рассмотрим каждую из этих групп в отдельности.

Моделирование данных:

используемая модель данных. Существует множество моделей данных, самые распространенные – иерархическая, сетевая, реляционная, объектно-реляционная и объектная. Вопрос об использовании той или иной модели должен решаться на начальном этапе проектирования информационной системы;
триггеры и хранимые процедуры. Триггер - программа базы данных, вызываемая всякий раз при вставке, изменении или удалении строки таблицы. Триггеры обеспечивают проверку любых изменений на корректность, прежде чем эти изменения будут приняты. Хранимая процедура – программа, которая хранится на сервере и может вызываться клиентом. Поскольку хранимые процедуры выполняются непосредственно на сервере базы данных, обеспечивается более высокое быстродействие, нежели при выполнении тех же операций средствами клиента БД. В различных программных продуктах для реализации триггеров и хранимых процедур используются различные инструменты;
средства поиска. Некоторые современные системы имеют встроенные дополнительные средства контекстного поиска;
предусмотренные типы данных. Здесь следует учесть два фактически независимых критерия: базовые или основные типы данных, заложенные в систему, и наличие возможности расширения типов. В то время как отклонения базовых наборов типов данных у современных систем от некоего стандартного, обычно, невелики, механизмы расширения типов данных в системах того или иного производителя существенно различаются;
реализация языка запросов. Все современные системы совместимы со стандартным языком доступа к данным SQL-92, однако многие из них реализуют те или иные расширения данного стандарта.

Особенности архитектуры и функциональные возможности:

мобильность. Мобильность – это независимость системы от среды, в которой она работает. Средой в данном случае является как аппаратура, так и программное обеспечение (операционная система);
масштабируемость. При выборе СУБД необходимо учитывать, сможет ли данная система соответствовать росту информационной системы, причем рост может проявляться в увеличении числа пользователей, объема хранимых данных и объеме обрабатываемой информации;
распределенность. Основной причиной применения информационных систем на основе баз данных является стремление объединить взгляды на всю информацию организации. Самый простой и надежный подход - централизация хранения и обработки данных на одном сервере. К сожалению, это не всегда возможно и приходится применять распределенные базы данных. Различные системы имеют разные возможности управления распределенными базами данных;
сетевые возможности. Многие системы позволяют использовать широкий диапазон сетевых протоколов и служб для работы и администрирования.

Контроль работы системы:

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

Особенности разработки приложений:

многие производители СУБД выпускают также средства разработки приложений для своих систем. Как правило, эти средства позволяют наилучшим образом реализовать все возможности сервера, поэтому при анализе СУБД стоит рассмотреть также и возможности средств разработки приложений;
средства проектирования. Некоторые системы имеют средства автоматического проектирования, как баз данных, так и прикладных программ.
многоязыковая поддержка. Поддержка большого количества национальных языков расширяет область применения системы и приложений, построенных на ее основе;
возможности разработки Web-приложений. При разработке различных

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

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

Производительность:

рейтинг TPC (Transactions per Cent). Для тестирования производительности применяются различные средства, и существует множество тестовых рейтингов. Одним из самых популярных и объективных является TPC-анализ производительности систем. Фактически TPC анализ рассматривает композицию СУБД и аппаратуры, на которой эта СУБД работает. Показатель TPC – это отношение количества запросов обрабатываемых за некий промежуток времени к стоимости всей системы;
возможности параллельной архитектуры. Для обеспечения параллельной обработки данных существует, как минимум, два подхода: распараллеливание обработки последовательности запросов на несколько процессоров, либо использование нескольких компьютеров-клиентов, работающих с одной БД, которые объединяют в так называемый параллельный сервер;
возможности оптимизирования запросов. При использовании непроцедурных языков запросов их выполнение может быть неоптимальным. Поэтому необходимо произвести процесс оптимизации запросов, т.е. выбрать такой способ выполнения, когда по начальному представлению запроса путем его синтаксических и семантических преобразований вырабатывается процедурный план выполнения запроса, наиболее оптимальный при существующих в базе данных управляющих структурах.

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

Рассмотрим более подробно следующие критерии:

многоуровневая система защиты. Информационная система организации почти всегда включает в себя секретную информацию, поэтому для предотвращения несанкционированного доступа используется служба идентификации пользователей. Уровень защиты может быть различным. Кроме непосредственной идентификации пользователей при входе в систему может использоваться также механизм шифрования данных при передаче по линиям связи;
восстановление после сбоев. При возникновении программных или аппаратных сбоев целостность, да и работоспособность всей системы может быть нарушена. От того, как эффективно спланирован механизм восстановления после сбоев, зависит жизнеспособность системы;
резервное копирование. В результате аппаратного сбоя может быть частично поврежден или выведен из строя носитель информации и тогда восстановление данных невозможно, если не было предусмотрено резервное копирование базы данных, или ее части. Резервное копирование спасает и в ситуациях, когда происходит логический сбой системы, например при ошибочном удалении таблиц. Существует множество механизмов резервирования данных (хранение одной или более копий всей базы данных, хранение копии ее части, копирование логической структуры и т.д.). Зачастую в систему закладывается возможность использования нескольких таких механизмов;
откат изменений. При выполнении транзакции применяется простое правило – либо транзакция выполняется полностью, либо не выполняется вообще. Это означает, что в случае сбоев, все результаты недоведенных до конца транзакций должны быть аннулированы. Механизм отката может иметь различное быстродействие и эффективность;

Требования к рабочей среде:

поддерживаемые аппаратные платформы;
минимальные требования к оборудованию;
максимальный размер адресуемой памяти, поскольку почти все современные системы используют свою файловую систему, немаловажным фактором является то, какой максимальный объем физической памяти они могут использовать;
операционные системы, под управлением которых способна работать СУБД.

Смешанные критерии:

качество и полнота документации. К сожалению, не все системы имеют полную и подробную документацию;
локализованность. Возможность использования национальных языков не во всех системах реализована полностью;
модель формирования стоимости. Как правило, производители СУБД используют определенные модели формирования стоимости. Например, стоимость одного и того же продукта может существенно изменяться в зависимости от того, сколько пользователей будет с ним работать;
стабильность производителя;
распространенность СУБД.

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

Перечень критериев поможет осознать масштабность задачи и выполнить ее адекватную постановку.

Следует отметить, что по существующей практике решение об использовании той или иной СУБД принимает один человек – обычно, руководитель предприятия, а он может опираться отнюдь не на технические критерии. Здесь свою роль могут сыграть такие, с технической точки зрения, незначительные факторы как рекламная раскрутка компании-производителя СУБД, использование конкретных систем на других предприятиях, стоимость. При этом последний фактор может трактоваться в двух противоположных смыслах в зависимости от финансового состояния и политики предприятия. С одной стороны, это может быть принцип, – чем дороже, тем лучше. С другой стороны – культивирование почти бесплатного использования продукта, вплоть до “взлома” его лицензионной защиты. Очевидно, последний подход чреват коллизиями и не может привести к успеху в долгосрочной работе.

В рамках данной работы были детально проанализированы следующие СУБД:

Microsoft SQL Server 2000;
Oracle8;
Microsoft Access 2003.

Результаты их сравнения представлены в таблице 1.

Название	Microsoft SQL Server 2000	Oracle8	Microsoft Access 2003
1	2	3	4
Используемая ОС	Windows 98/Me, Windows NT/2000/XP, Windows CE, Windows NT/2000/2003 Server,	Vax VMS, Windows NT/2000/XP, Unix, Solaris, HP-UX, AIX, Linux, SCO Unix	Windows 2000/XP
Требования к аппаратному обеспечению	64 МБ ОЗУ, 100 МБ на жестком диске	256 МБ ОЗУ, 500 МБ на жестком диске	128 МБ ОЗУ, 180 МБ на жестком диске
Поддерживаемая модель данных	Реляционная	Реляционная	Реляционная
Формат файла	*.mdf	.dbf, .log, *.fmx	*.mdb
Поддерживаемые объекты БД	Индексы, триггеры, хранимые процедуры, домены, таблицы, динамические таблицы	Индексы, кластеры, пакеты, триггеры, последовательности, хранимые процедуры, синонимы, таблицы, представления	Таблицы, формы, отчеты, макросы, модули
Технология создания БД и объектов БД	SQL скрипты, с помощью визуальных средств Enterprise Manager	С помощью DataBase configuration assistent Enterprise и Manager Configuration Assistant	С помощью использования конструкторов, мастеров, языка SQL
Поддержка сервера БД	Есть	Можно работать с БД на разных серверах	Ограничена
Возможность создания локальной БД	+	+	+
Поддержка стандарта SQL	+	+	+
Наличие встроенного языка для разработки приложений	Visual Basic .NET, C#, J#	Java	Visual Basic for Application
Средства поддержки ограничения целостности БД	Первичные ключи, внешние ключи, уникальность поля, условия корректности поля, GUID	Механизмы для поддержания ссылочной целостности и контроля вводимой информации	Первичные ключи, внешние ключи, условия корректности поля
Возможности реализации прав доступа для отдельных пользователей	Политика пользователей, ролей, на уровне сервера и на уровне БД	Централизованное управление пользователями (встроенная система безопасности, проверка пароля пользователя на входе, позволяет предоставлять избирательный доступ к каждому объекту базы данных)	Защита файлов паролем
Наличие встроенных средств для резервного копирования и восстановления БД из резервной копии	Широкие возможности по работе с резервными копиями с учетом оптимизации под работу с различными типами устройств резервного копирования	Export – сохраняет данные и их структуру во внешний бинарный файл; Import –воссоздает данные и их структуру из выбранного бинарного файла экспорта; SQL * Loader – гибкий инструмент, с его помощью можно загрузить данные из обычных текстовых файлов в БД Oracle. Может осуществлять резервное копирование on-line
Наличие средств передачи данных в Word и Excel	–	–	+
Наличие средств для получения отчетов	+	+	+
Наличие встроенных средств для резервного копирования и восстановления БД из резервной копии	Широкие возможности по работе с резервными копиями с учетом оптимизации под работу с различными типами устройств резервного копирования	Export – сохраняет данные и их структуру во внешний бинарный файл; Import –воссоздает данные и их структуру из выбранного бинарного файла экспорта; SQL * Loader – гибкий инструмент, с его помощью можно загрузить данные из обычных текстовых файлов в БД Oracle. Может осуществлять резервное копирование on-line	Резервное копирование файла БД
Простота или сложность работы с СУБД	Сложно	Сложно	Просто

Проанализировав вышеуказанную таблицу, можно сделать ряд выводов:

при создании БД единственная непереносимая СУБД – Microsoft Access;
наиболее требовательна к особым системным ресурсам СУБД Oracle;
все рассмотренные СУБД поддерживают реляционную модель данных;
большее количество поддерживаемых объектов реализовано в СУБД Oracle;
разработка БД может вестись как визуально, так и при помощи встроенных языков, благодаря чему будут удовлетворены запросы пользователей разного уровня;
из рассмотренных СУБД, только Access не обладает встроенными средствами для создания резервных копий;
данные СУБД обладают встроенными средствами для получения отчетов;
в данных СУБД реализованы права разграничения доступа, наиболее эффективно в Oracle и Microsoft SQL Server;
СУБД Microsoft Access является локальной СУБД, хотя в ней предусмотрена возможность создания сетевой БД, а две другие – сетевыми;

Для дипломного проекта необходимо использовать Microsoft SQL Server, так как именно данная СУБД входит в состав ПК, используемого на предприятии.

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

Результаты сравнения средств разработки приложений представлены в таблице 2.

Название	Delphi	C++Builder
Версия, производители	Delphi 6, Borland	С++ Builder 6, Borland
Подход к разработке ПО	ООП	ООП
Механизм доступа к БД	Через специальные компоненты	BDE, dbExpress, ADO,
Утилиты для работы с БД	+	+
Поддержка стандарта языка SQL	+	+
Наличие компонент для работы с БД	+	+
Наличие компонент построения отчетов и диаграмм	+	+
Поддержка Windows подобного интерфейса	+	+
Средства поддержки транзакций	+	+
Возможность создания запускаемого файла	+	+

Вывод:

рассмотренные средства разработки приложений являются объектно-ориентированными;
все они поддерживают стандарт языка SQL;
у рассмотренных средств имеются компоненты для работы с БД и компоненты построения отчётов и диаграмм;
данные средства поддерживают Windows подобный интерфейс, это упрощает проектирование и использование приложения БД;
у всех имеются средства поддержки транзакций;
рассмотренные средства разработки приложений довольно просты в работе с инструментальным средством;
возможность создания запускаемого файла без запуска инструментального средства не существует только у Microsoft Access.

На выбор операционной системы (ОС) также влияет много факторов. Большое разнообразие типов компьютеров, используемых в вычислительных сетях, влечет за собой разнообразие ОС: для рабочих станций, для серверов сетей уровня отдела и серверов уровня предприятия в целом. К ним могут предъявляться различные требования по производительности и функциональным возможностям.

Желательно, чтобы они обладали свойством совместимости, которое позволило бы обеспечить совместную работу различных ОС.

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

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

масштабируемостью, то есть способностью одинаково хорошо работать в широком диапазоне различных количественных характеристик сети;
совместимостью с другими продуктами, то есть способностью работать в сложной гетерогенной среде интерсети в режиме plug-and-play.

Корпоративная сетевая ОС должна поддерживать более сложные сервисы. Подобно сетевой ОС рабочих групп, сетевая ОС масштаба предприятия должна позволять пользователям разделять файлы, приложения и принтеры, причем делать это для большего количества пользователей и объема данных и с более высокой производительностью. Кроме того, сетевая ОС масштаба предприятия обеспечивает возможность соединения разнородных систем - как рабочих станций, так и серверов. Например, даже если ОС работает на платформе Intel, она должна поддерживать рабочие станции UNIX, работающие на RISC-платформах. Аналогично, серверная ОС, работающая на RISC-компьютере, должна поддерживать DOS, Windows и OS/2. Сетевая ОС масштаба предприятия должна поддерживать несколько стеков протоколов (таких как TCP/IP, IPX/SPX, NetBIOS, DECnet и OSI), обеспечивая простой доступ к удаленным ресурсам, удобные процедуры управления сервисами, включая агентов для систем управления сетью.

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

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

Такие сетевые ОС, как Banyan Vines, Novell NetWare 4.x, IBM LAN Server, Sun NFS, Microsoft LAN Manager и Windows NT Server, могут служить в качестве операционной системы предприятия, в то время как ОС NetWare 3.x, Personal Ware, Artisoft LANtastic больше подходят для небольших рабочих групп.

Критериями для выбора ОС масштаба предприятия являются следующие характеристики:

органичная поддержка многосерверной сети;
высокая эффективность файловых операций;
возможность эффективной интеграции с другими ОС;
наличие централизованной масштабируемой справочной службы;
хорошие перспективы развития;
эффективная работа удаленных пользователей;
разнообразные сервисы: файл-сервис, принт-сервис, безопасность данных и отказоустойчивость, архивирование данных, служба обмена сообщениями, разнообразные базы данных и другие;
разнообразные программно-аппаратные хост-платформы: IBM SNA, DEC NSA, UNIX;
разнообразные транспортные протоколы: TCP/IP, IPX/SPX, NetBIOS, AppleTalk;
поддержка многообразных операционных систем конечных пользователей: DOS, UNIX, OS/2, Mac;
поддержка сетевого оборудования стандартов Ethernet, Token Ring, FDDI, ARCnet;
наличие популярных прикладных интерфейсов и механизмов вызова удаленных процедур RPC;
возможность взаимодействия с системой контроля и управления сетью, поддержка стандартов управления сетью SNMP.

Конечно, ни одна из существующих сетевых ОС не отвечает в полном объеме перечисленным требованиям, поэтому выбор сетевой ОС, как правило, осуществляется с учетом производственной ситуации и опыта.

Выбор и обоснование математического аппарата для расчета и прогнозирования энергопотребления

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

Задача интерполирования состоит в том, чтобы по значениям функции f(x) в нескольких точках отрезка восстановить ее значения в остальных точках данного отрезка. Такая постановка задачи допускает сколь угодно много решений.

Задача интерполирования возникает, например, в том случае, когда известны результаты измерений y_k = f(x_k) некоторой физической величины f(x) в точках x_k, k = 0, 1,…, n и требуется определить ее значение в других точках.

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

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

2.3.1. Интерполирование алгебраическими многочленами

Пусть функциональная зависимость задана таблицей y_{0 =}f(x₀), y₁= f(x₁), …, y_n₌f(x_n). Обычно задача интерполирования формулируется так: найти многочлен P(x) = P_n(x) степени не выше n, значения которого в точках x_i (i = 0, 1, 2, …, n) совпадают со значениями данной функции, то есть P(x_i) = y_i.

Геометрически это означает, что нужно найти алгебраическую кривую вида:

(1)

проходящую через заданную систему точек М_i(x_i,y_i) (рисунок 9). Многочлен Р(х) называется интерполяционным многочленом. Точки x_i (i = 0, 1, 2, …, n) называются узлами интерполяции.

Для любой непрерывной функции f(x) сформулированная задача имеет единственное решение. Действительно, для отыскания коэффициентов а₀, а₁, а₂,…, а_n получаем систему линейных уравнений

(2)

определитель которой (определитель Вандермонда) отличен от нуля, если среди точек x_i (i = 0, 1, 2,…, n) нет совпадающих.

Решение системы (2) можно записать различным образом. Однако наиболее употребительна запись интерполяционного многочлена в форме Лагранжа и в форме Ньютона.

Запишем без вывода интерполяционный многочлен Лагранжа:

(3)

Нетрудно заметить, что старшая степень аргумента х в многочлене Лагранжа равна n. Кроме этого, несложно показать, что в узловых точках значение интерполяционного многочлена Лагранжа соответствует заданным значениям f(x_i).

2.3.2. Интерполяционная формула Ньютона

Интерполяционная формула Ньютона позволяет выразить интерполяционный многочлен P_n(x) через значение f(x) в одном из узлов и через разделенные разности функции f(x), построенные по узлам x₀, x₁, …, x_n. Эта формула является разностным аналогом формулы Тейлора:

(4)

Прежде чем приводить формулу Ньютона, рассмотрим сведения о разделенных разностях. Пусть в узлах известны значения функции f(x). Предполагаем, что среди точек x_k, k = 0, 1,…, n нет совпадающих. Тогда разделенными разностями первого порядка называются отношения:

(5)

Будем рассматривать разделенные разности, составленные по соседним узлам, то есть выражения . По этим разделенным разностям первого порядка можно построить разделенные разности второго порядка:

(6)

Аналогично определяются разности более высокого порядка. То есть пусть известны разделенные разности k-го порядка тогда разделенная разность k+1-го порядка определяется как

(7)

Интерполяционным многочленом Ньютона называется многочлен

(8)

Показано, что интерполяционный многочлен Лагранжа (3) совпадает с интерполяционным многочленом Ньютона (8).

Замечания:

в формуле (8) не предполагалось, что узлы x₀, x₁,…, x_n расположены в каком-то определенном порядке. Поэтому роль точки x₀ в формуле (8) может играть любая из точек x₀, x₁,…, x_n. Соответствующее множество интерполяционных формул можно получить из (8), перенумеровав узлы. Например, тот же самый многочлен P_n(x) можно представить в виде:

(9)

если x₀<x₁<x₂<…<x_n, то (2.8) называется формулой интерполирования вперед, а (9) – формулой интерполирования назад.
интерполяционную формулу Ньютона удобнее применять в том случае, когда интерполируется одна и та же функция f(x), но число узлов интерполяции постепенно увеличивается.

2.3.3. Сходимость интерполяционного процесса

Обсудим следующий вопрос: будет ли стремиться к нулю погрешность интерполирования f(x) – L_n(x), если число узлов n неограниченно увеличивать:

свойства сходимости или расходимости интерполяционного процесса зависят как от выбора последовательности сеток, так и от гладкости функции f(x).
известны примеры несложных функций, для которых интерполяционный процесс расходится.

Так последовательность интерполяционных многочленов, построенных для непрерывной функции по равноотстоящим узлам на отрезке
[-1, 1], не сходится к функции ни в одной точке отрезка [-1, 1], кроме точек –1, 0, 1. На рисунке 10 в качестве иллюстрации изображен график многочлена L₉(x) при , построенного для функции по равноотстоящим узлам на отрезке [-1, 1].

Чтобы избежать этих некорректностей, в практике вычислений обычно избегают пользоваться интерполяционными многочленами высокой степени.

2.3.4. Интерполирование сплайнами

Многочлен Лагранжа или Ньютона на всем отрезке [a, b] с использованием большого числа узлов интерполирования часто приводит к плохому приближению, что объясняется накоплением погрешностей в ходе вычислений. Кроме того, из-за расходимости процесса интерполирования увеличение числа узлов не обязано приводить к повышению точности. В силу выше сказанного весь отрезок [a, b] разбивается на частичные интервалы и на каждом из них приближающая функция заменяется многочленом невысокой степени. Такая интерполяция называется кусочно-полиномиальной интерполяцией.

Сплайн-функцией называют кусочно-полиномиальную функцию, определенную на отрезке [a, b] и имеющую на этом отрезке некоторое число непрерывных производных. Слово сплайн означает гибкая линейка, которую используют для проведения гладких кривых через определенное число точек плоскости. Преимущество сплайнов – сходимость и устойчивость процесса вычисления. Рассмотрим частный случай (часто используемый на практике), когда сплайн определяется многочленом третьей степени.

Пусть на отрезке [a, b] задана непрерывная функция . Введем неравномерную сетку узлов причем , , где i от 0 до n.

Сплайном соответствующим функции этим узлам называется функция S(х), которая:

а) на каждом частичном отрезке является многочленом третьей степени;

б) непрерывна на [a, b];

в) .

Докажем существование и единственность такого сплайна. На каждом частичном отрезке [x_i_-1, x_i] будем искать сплайн , где многочлен третьей степени.

, (10)

т.е. для [x_i_-1, x_i] нужно построить такую функцию, где a_i, b_i, c_i, d_i нам неизвестны, найдем их:

Доопределим . Требование непрерывности функции S(x) приводят к условиям: где i от 1 до (n-1).

Введем

Получаем систему с тремя неизвестными, которые нужно найти b_i, c_i, d_i. Для этого воспользуемся граничными условиями для сплайн-функции: . Тогда получим систему уравнений:

. (11)

Решая систему методом подстановки (исключаем из (10) неизвестные b_i, d_i) получим систему:

. (12)

Система (11) дает нам трех диагональную матрицу. Эта система может быть решена методом прогонки или Гаусса. После ее решения находятся:

, (13)

. (14)

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

. (15)

Если функция периодическая то используется тригонометрическая интерполяция с периодом L, которая строиться с помощью тригонометрического многочлена (i от 1 до 2π+1):

. (16)

2.3.5. Аппроксимация методом наименьших квадратов

Пусть в результате исследования некоторой величины x значениями x₁, x₂, …, x_n поставлены в соответствие значения y₁, y₂, …, y_n некоторой величины у.

Требуется подобрать вид аппроксимической зависимости y=f(x) связывающей переменные х и у. Во-первых: заданные табличные функции f(x) имеют достаточно большое количество узлов; во-вторых: значения таблично заданных функций отягощены погрешностями. Тогда проводить приближения функции с помощью многочлена нецелесообразно, так как:

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

Будем искать приближающую функцию из следующих соображений:

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

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

, (17)

где – это значение эксперимента.

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

, (18)

такая аппроксимация называется линейной.

Нам неизвестна степень обобщающего многочлена, подберем ее так, чтобы было наименьшим и:

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

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

Для этого воспользуемся условием существования экстремума, а именно, найдем частные производные по всем переменным и прировняем их к нулю. Получим систему вида:

. (19)

Система (19) – система линейных уравнений относительно .

Введем определение чтобы лучше записать (19).

Определение: Скалярным произведением функции f на g на множестве называется

. (20)

Тогда систему (19) можно записать в виде:

. (21)

Системы (19) и (21) будем называть нормальными системами уравнений. Решив эти системы, мы найдем коэффициенты , а значит, найдем вид аппроксимирующего многочлена. Напомним, что это возможно, когда узлы, не равноотстоящие, и базисные вектора линейно не зависимы. Осталось определить m.

Алгоритм выбора степени «m»

В случае когда m=n мы получим интерполяционный многочлен, поэтому m<<n. Так же необходимо задать и учитывая следующее:

> 0 и >0 должны быть такими, чтобы находилось между ними;
первоначально m выбирают произвольно, но учитывая условие, что m<<n;
выбрав m строят системы (19) и (21), решив которые находят С₀…С_m;
используя найденные коэффициенты вычисляется и проверяется попала ли она в промежуток между и .Если попала, то степень многочлена выбрана правильно, иначе:
если > то степень необходимо уменьшить хотя бы на единицу;
если < то степень необходимо увеличить хотя бы на единицу;

д) затем строить приближающую функцию.

2.4. Разработка схемы функционирования программного средства

Функциональная схема отображает управление операциями и потоками данных в системе. Функциональная схема состоит:

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

Функциональная схема ПС представлена на рисунке 12.

При запуске программной системы производится запрос имени и пароля пользователя и осуществляется проверка. Если введенный пароль неверен, то выдается сообщение о неверном вводе пароля.

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

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

Удаление пользователя производится также администратором, результатом будет измененная база данных.

Администратор должен в соответствии со своими обязанностями проводить своевременно резервирование базы данных, с ее последующим восстановлением при необходимости.

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

Основная работа пользователя заключается в обработке исходных данных, хранящихся в базе данных, с целью их восстановления. Обработка производится математическими методами, результатом работы являются восстановленные данные, которые записываются в базу данных.

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

Для обоих видов пользователей доступна функция получения справки.

2.5. Разработка и реализация базы данных

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

Основными целями проектирования БД являются:

представление данных и связей между ними, необходимых для всех областей применения системы БД и любых существующих групп пользователей;
создание модели данных, способной поддерживать выполнение любых требуемых транзакций обработки данных;
разработка предварительного варианта проекта, структура которого позволяет удовлетворить все основные требования, предъявляемые к производительности системы – например, ко времени реакции системы.

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

Для каждого проекта существует ряд абсолютных требований, как правило, это:

максимальное время, отпущенное на проект;
максимальное количество денег, которое м.б. потрачено;
масса других требований и ограничений (недостаточная подготовка специалистов, отсутствие ТЗ на проектирование, недопонимание сотрудниками автоматизируемых подразделений сути внедрения автоматизации работ и т.п.).

Проектирование БД охватывает 3 основные области:

проектирование конкретных объектов, которые будут реализованы в БД (домены, таблицы, хранимые процедуры, триггеры, индексы).
проектирование конкретных экранных форм, отчетов, программ, которые будут сопровождать данные в БД и обеспечивать выполнение запросов к ним.
при определенных обстоятельствах в процессе проектирования также необходимо учитывать конкретную среду или технологию – например, топологию сети, конфигурацию аппаратных средств, использование архитектуры клиент/сервер, параллельной обработки данных, распределенной архитектуры БД.

В идеальном мире, используя существующие методы и средства проектирования БД, можно было бы построить совершенно четкую и логичную структуру БД, которая позволила бы достичь разрабатываемой системе максимальной производительности.

Проектирование в реальном мире заключается в достижении компромиссов и строится на информированном принятии решений (ограничения;

видение разработчиком определенной технологической цепочки обработки информации, а в реальном состоянии дел на предприятии реализовать эту цепочку не получается по каким-либо причинам, развитие ИТ, переход на новую архитектуру; увеличение количества требований, недостаточный объем знаний у проектировщика).

Распространены два основных подхода к проектированию систем баз данных: "нисходящий" и "восходящий".

Восходящий подход.

Структурное проектирование снизу-вверх (восходящее проектирование), или процесс синтеза – попытка получения целого (описания ПрО) на основе составляющих его частей (реинжениринг): ДЛМ (в первом приближении) – нормализация – ДЛМ (в заданной НФ) – ИЛМ – ПрО.

Работа начинается с самого нижнего уровня – уровня определения атирибутов сущностей (свойств объектов), которые на основе анализа существующих между ними связей группируются в отношения, представляющие типы сущностей (объекты) и связи между ними. Затем осуществляется процесс нормализации. Нормализация предусматривает идентификацию требуемых атрибутов с последующим созданием из них нормализованных таблиц, основанную на зависимостях между этими атрибутами. Устаревшая методика, достаточно сложная.

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

Структурное проектирование сверху-вниз (нисходящее проектирование), или процесс анализа – разделение целого на составные части и последующее изучение этих частей: ПрО – ИЛМ – ДЛМ (приблиз в 3НФ) – нормализация – ДЛМ (в зад НФ).

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

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

2.5.1. Пользователи программного средства. Уровни доступа пользователей

Как и другие автоматизированные информационные системы, разрабатываемое программное средство имеет нескольких пользователей, осуществляющих различные функции и наделенных различными правами доступа к данным. Такими пользователями являются: системный программист, сотрудник отдела АСКУЭ, администратор БД.

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

Основным пользователем программной системы является сотрудник отдела АСКУЭ, который занимается контролем и учетом показателей и режимов потребления энергии и энергоносителей, а также контролем параметров и режимов работы промышленного оборудования.

В основные задачи администратора входит создание БД ПТК «ЭКОМ», дальнейшее администрирование БД программно-технического комплекса (ПТК) «ЭКОМ». Настройка параметров работы MS SQL Server. Создание учетных записей пользователей БД ПТК «ЭКОМ».

Роли (role) БД определяют возможности пользователей по доступу к данным и соответственно права пользователей при работе с приложением, использующим эти данные. В зависимости от используемых приложений ПО ПТК и соответственно выполняемых скрипт-файлов в БД ПТК «ЭКОМ» должны быть созданы соответствующие роли.

Кроме того, программным средством может воспользоваться руководитель, с целью контроля работы ПТК «ЭКОМ».

Уровни доступа пользователей представлены в таблице 3.



Autoread
Channels
ID_OBJ
LINES
Mains_е
Schetch
Shorts
Shorts_Е
SYSUSERS
USD
UserLimits

В таблице использованы сокращения: R – Чтение (Read); I – Добавление (Insert); U – Обновление (Update); D – Удаление (Delete); E – Выполнение триггеров и хранимых процедур (Execute).

2.5.2. Инфологическая модель предметной области

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

Результат – ИЛМ предметной области, представленная в виде ER-диаграммы предметной области, формализованного и неформализованного описания.

В процессе развития теории БД уже в 70-80-х годах было предложено несколько моделей данных, названных объектными, используемыми для создания ИЛМ ПО:

в 1976 г. – семантическая модель, предложенная Питером Ченом – модель "сущность-связь" – Entity Relationship model – ER-модель, которая в настоящее время стала самой распространенной;
в 1981 г. – семантическая модель, предложенная Хаммером (Hammer) и Мак-Леоном (McLeon);
в 1981 г. – функциональная модель Шипмана (Shipman);
начало 80-х. – расширенная (Enchanced ER- EER) ER-модель, предложенная (R.Barker). EER включает в себя все концепции ER и дополнена новыми семантическими концепциями.

Для создания информационно-логической (инфологической) модели предметной области используем методологию Ричарда Баркера. По данной методологии уникальный идентификатор обозначают решеткой (#), обязательное поле звездочкой (*), не обязательное кружком (○), обязательную связь сплошной линией, не обязательную пунктирной линией, множественность связи «вороньей» лапой. Каждый класс объектов оформляется в виде прямоугольника с скругленными краями.

При анализе предметной области были выявлены 11 сущностей и связи между ними, представленные на рисунке 13.

2.5.3. Даталогическая модель базы данных

По правилам нисходящего проектирования даталогическая модель (ДЛМ) на основе реляционной модели данных строится из ИЛМ путем преобразования классов объектов и связей между классами объектов. Каждый класс объектов отображается в виде реляционного отношения. Графическое изображение ДЛМ БД представляется в виде логической структуры с указанием первичных и внешних ключей и обязательным отображением связей и указанием типа связи.

Существует различные способы представления реляционных отношений:

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

ДЛМ БД представлена в графическом виде на рисунке 14.

2.5.4. Физическая модель БД

Техническое описание таблиц БД представлено в таблицах 4 – 14.

Описание на языке SQL представлено в приложении А.

Имя поля	ID	MeasureDate	ID_Channel	Value	State
Ключ	Primary Key	Primary Key	Foreign Key
Тип, длина	Int	datetime	int	float	smallint
Обязательность значения	NOT NULL	NOT NULL	NOT NULL	NOT NULL	NULL
Логическое ограничение на поле	Check(value>0)	Check(value>0)	Check(value>0)

Имя поля	ID	MeasureDate	ID_Channel	Value	State
Ключ	Primary Key	Primary Key	Foreign Key
Тип, длина	int	datetime	int	float	smallint
Обязательность значения	NOT NULL	NOT NULL	NOT NULL	NOT NULL	NULL
Логическое ограничение на поле	Check(value>0)	Check(value>0)	Check(value>0)

Имя поля	ID	MeasureDate	ID_Schetch	Value	State
Ключ	Primary Key	Primary Key	Foreign Key
Тип, длина	int	datetime	int	float	smallint
Обязательность значения	NOT NULL	NOT NULL	NOT NULL	NOT NULL	NULL
Логическое ограничение на поле	Check(value>0)	Check(value>0)	Check(value>0)

Имя поля	ID	MeasureDate	ID_Schetch	Value	State
Ключ	Primary Key	Primary Key	Foreign Key
Тип, длина	int	datetime	int	float	smallint
Обязательность значения	NOT NULL	NOT NULL	NOT NULL	NOT NULL	NULL
Логическое ограничение на поле	Check(value>0)	Check(value>0)	Check(value>0)

Имя поля	Ключ	Тип, длина	Обязательность значения	Логическое ограничение на поле
ID	Primary Key	int	NOT NULL	Check(value>0)
Substation		char(30)	NULL
Name		char(30)	NOT NULL
Type		char(20)	NULL
Prod_Date		char(10)	NOT NULL
Prod_Number		char(20)	NOT NULL
Precesion		float	NOT NULL
Verificat_Date		char(10)	NOT NULL
K_I		float	NOT NULL
K_U		float	NOT NULL

Имя поля	ID_OBJ	Name	IsCommerce
Ключ	Primary Key
Тип, длина	int	char(30)	bit
Обязательность значения	NOT NULL	NOT NULL	NOT NULL
Логическое ограничение на поле	Check(value>0)

Имя поля	Ключ	Тип, длина	Обязательность значения	Логическое ограничение на поле
ID	Primary Key	int	NOT NULL	Check(value>0)
ID_USPD	Foreign Key	int	NULL	Check(value>0)
ID_Schetch	Foreign Key	int	NOT NULL	Check(value>0)
TypeChan		char(1)	NULL
NumChan		smallint	NULL
TimeLastShort		datetime	NULL
TimeLastMain		datetime	NULL
TimeLastDay		datetime	NULL
TimeLastMonth		datetime	NULL
TimeLastYear		datetime	NULL
Name		char(40)	NULL

Имя поля	ID	ID_Object	ID_Schetch	Adds
Ключ	Primary Key	Foreign Key	Foreign Key
Тип, длина	int	int	int	smallint
Обязательность значения	NOT NULL	NULL	NULL	NOT NULL
Логическое ограничение на поле	Check(value>0)	Check(value>0)	Check(value>0)

Имя поля	Ключ	Тип, длина	Обязательность значения	Логическое ограничение на поле
ID_USD	Primary Key	int	NOT NULL	Check(value>0)
Name		char(30)	NULL
NumUSD		smallint	NULL
NumCOMPort		smallint	NULL
IsWorking		bit	NOT NULL
TypeCommun		char(10)	NULL
Speed		int	NULL
TypeUSD		char(10)	NULL

Таблица 13. Реляционное отношение SYSUSERS

Имя поля	ID_User	Name
Ключ	Primary Key
Тип, длина	int	char(50)
Обязательность значения	NOT NULL	NULL
Логическое ограничение на поле	Check(value>0)

Имя поля	ID	ID_Object	ID_Users	CanUse	CanEdit
Ключ	Primary Key	Foreign Key	Foreign Key
Тип, длина	int	int	int	bit	bit
Обязательность значения		NOT NULL	NOT NULL	NOT NULL	NOT NULL
Логическое ограничение на поле	Check(value>0)	Check(value>0)	Check(value>0)

2.6. Разработка и реализация алгоритма программного средства

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

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

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

При выборе пользователем действия 3, осуществляется вызов метода Ньютона (осуществляется интерполирование). При невозможности использования данного метода для выбранных данных на экран выдается сообщение об ошибке, и дается краткое руководство для дальнейшего действия. После этого программа переходит в режим меню.

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

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

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

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

При выборе пользователем действия 8 осуществляется выход из программы.

Алгоритм разработанного программного средства показан на рисунке 15. На рисунке 16 представлена схема алгоритма выбора подходящего метода программным средством. Схема разработанного алгоритма метода Ньютона приведена на рисунке 17.

2.7. Описание работы программы

Алгоритм разработанного программной системы показан на рисунке 2.8.

Программа состоит из четырех модулей. При запуске программы создается главная форма, в ней в процедуре TForm1.FormCreate(Sender: TObject); запускается заставка (рисунок 18) и, одновременно, считываются данные из базы данных.

Затем открывается окно Form3, где пользователь/администратор должен ввести пароль, после нажатия на кнопку “Вход” запустится процедура TForm3.Button1Click(Sender: TObject), которая проверяет правильность ввода пароля: if s=Edit1.Text then Form1.ShowModal. Если пароль верен, то отображается главная форма, представленная на рисунке 19.

Если пароль не верен: else ShowMessage('Неверный логин или пароль!'), то выводится сообщение.

За отображение графика отвечает процедура Zapmas, происходит вывод графика (рисунок 20) и заполнение массива данными (считывание нужных данных по конкретному счетчику).

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

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

При выборе пользователем действия 2, осуществляется просмотр таблиц базы (рисунок 21), какие-то другие действия, кроме чтения данных пользователю недоступны. После этого программа переходит в режим меню.

При выборе пользователем действия 3, т.е. выборе соответствующего метода и нажатия на кнопку “Пуск”, осуществляется вызов метода Ньютона (процедура TForm1.met_niuton), осуществляется интерполирование. При невозможности использования данного метода для выбранных данных, за это отвечает процедура Proverka_dan, на экран выдается сообщение об ошибке, и дается краткое руководство пользователю для дальнейшего действия. После этого программа переходит в режим меню. Схематично представлено на рисунке 22.

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

При выборе пользователем действия 5, осуществляется вызов метода интерполирования сплайнами (процедура TForm1.met_splain), осуществляется интерполирование. При невозможности использования данного метода для выбранных данных на экран выдается сообщение об ошибке, и дается краткое руководство пользователю для дальнейшего действия. Представлено на рисунке 23.

Если метод оказывается подходящим, то найденные значения выводятся (процедура TForm1.viv_znach) на экран (рисунок 24) в соответствующее поле (StringGrid1). После этого программа переходит в режим меню.

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

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

При выборе пользователем действия 8 осуществляется выход из программы (procedure TForm1.Button2Click(Sender: TObject)).

По данному алгоритму разработано программное средство, программный код представлен в приложении Б.

2.8. Тестирование программного средства

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

Еще одним средством защиты является авторизация при входе в программное средство, на рисунке 26 показан пример сообщения об ошибке, которое появляется при некорректном вводе логина или пароля для авторизации на сервере баз данных.

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

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

2.9. Вывод

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

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

Заключение

В ходе разработки дипломной работы были решены вопросы практической реализации программного средства для расчета и прогнозирования энергопотребления в системе “АИИС КУЭ”.

В дипломной работе были решены следующие задачи:

проведен анализ литературы, определены методы решения поставленных задач;
разработана структура необходимых таблиц для программы доступа к базе данных;
реализованы хранимые процедуры базы данныз;
разработаны рекомендации к техническому и программному обеспечению.
дано руководство по эксплуатации программного средства.

Таким образом, внедрение разработанного программного продукта имеет принципиальное значение для решения задач по автоматизации функциональной деятельности ООО “Энергоучет”.

Список используемой литературы

WEB-сервер рекламно-издательского агентства КомпьютерПресс. Профессиональная разработка приложений с помощью Delphi 5 [Электронный ресурс] – Режим доступа: http://cpress.ru/, свободный. – Загл. с экрана.
Архангельский А.Я. Программирование в C++Builder – М.: Издательство «БИНОМ», 2002 – 1152 с.
Баженова И.Ю. Delphi 6: Самоучитель программиста. – М.: КУДИЦ-ОБРАЗ, 2002. – 432 с.
Вендеров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – М.: Финансы и статистика, 2000. – 352 с.
ГОСТ 19.701-90 ЕСПД. Схемы алгоритмов, программ, данных и систем. Обозначения условные и правила выполнения.
ГОСТ Р22.0.05-94. Безопасность в ЧС. Техногенные ЧС. Термины и определения.
Демидович Б.П., Марон И.А. Основы вычислительной математики. – М.: Наука, 1970. – 664 с.
Занько Н.Г., Корсаков Г.А., Малаян К.Р., Русак О.Н., Соловьев В.А. Безопасность жизнедеятельности: Учебное пособие по курсу "Безопасностьжизнедеятельности" для студентов всех специальностей. - СПб.: ЛТА, – 293 с.
Зубкова Т.М. Технология разработки программного обеспечения: Учебное пособие. – : ГОУ ТГУ, 2004. – 101 с.
Информационный форум CitForum [Электронный ресурс] – Режим доступа: http://citforum.ru/, свободный. – Загл. с экрана.
Мартин Грабер. Справочное руководство по SQL. – М.: Издательство «ЛОРИ», 1997. – 292 с.
Официальный сайт научно-производственной фирмы «Прософт-Е» [Электронный ресурс] – Режим доступа: http://www.prosoftural.ru/, свободный. – Загл. с экрана.
Официальный сайт предприятия ООО «Энергоучет» [Электронный ресурс] – Режим доступа: http://www.energouchet.org/, свободный. – Загл. с экрана.
Практикум по численным методам. / Л.Я. Егорова, Л.Л. Левин, Б.Г. Ослин и др. - Томск: Изд. ТГУ, 1979. – 212 с.
Ульман Дж., Уидом Дж. Введение в системы баз данных. – М.: Издательство «ЛОРИ», 2000. – 376с.

Приложение А

(обязательное)

SQL –скрипты

-- Этот скрипт создает БД NIS для работы программного средства «ЭП»

ALTER TABLE [dbo].[autoread] WITH NOCHECK ADD

CONSTRAINT [PK_autoread] PRIMARY KEY CLUSTERED

(

[id],

[Measuredate]

) ON [PRIMARY]

GO

ALTER TABLE [dbo].[mains_e] WITH NOCHECK ADD

CONSTRAINT [PK_mains_e] PRIMARY KEY CLUSTERED

(

[ID],

[MeasureDate]

) ON [PRIMARY]

GO

ALTER TABLE [dbo].[schetch] WITH NOCHECK ADD

CONSTRAINT [PK_schetch] PRIMARY KEY CLUSTERED

(

[ID]

) ON [PRIMARY]

GO

ALTER TABLE [dbo].[autoread] WITH NOCHECK ADD

CONSTRAINT [DF_autoread_Measuredate] DEFAULT ('02.01.2006') FOR [Measuredate]

GO

ALTER TABLE [dbo].[autoread] ADD

CONSTRAINT [FK_autoread_schetch] FOREIGN KEY

(

[id_schetch]

) REFERENCES [dbo].[schetch] (

[ID]

) ON DELETE CASCADE

GO

ALTER TABLE [dbo].[mains_e] ADD

CONSTRAINT [FK_mains_e_schetch] FOREIGN KEY

(

[ID_Schetch]

) REFERENCES [dbo].[schetch] (

[ID]

) ON DELETE CASCADE

GO

Создание таблицы Channels

CREATE TABLE [dbo].[Channels] (

[ID] [int] NULL ,

[Name] [char] (100) COLLATE Cyrillic_General_CI_AS NULL ,

[TypeChan] [char] (1) COLLATE Cyrillic_General_CI_AS NULL ,

[NumChan] [int] NULL ,

[ID_Schetch] [int] NULL ,

[TimeLastShort] [datetime] NULL ,

[TimeLastMain] [datetime] NULL ,

[TimeLastDay] [datetime] NULL ,

[TimeLastMonth] [datetime] NULL ,

[TimeLastYear] [datetime] NULL

) ON [PRIMARY]

GO

Создание таблицы ID_OBJ

CREATE TABLE [dbo].[ID_OBJ] (

[ID] [int] IDENTITY (1, 1) NOT NULL ,

[Name] [char] (60) COLLATE Cyrillic_General_CI_AS NOT NULL ,

[IsCommerce] [bit] NOT NULL

) ON [PRIMARY]

GO

Создание таблицы LINES

CREATE TABLE [dbo].[LINES] (

[ID] [int] NULL ,

[Adds] [smallint] NOT NULL

) ON [PRIMARY]

GO

Создание таблицы Mains_e

CREATE TABLE [dbo].[Mains_e] (

[ID] [int] NOT NULL ,

[MeasureDate] [datetime] NOT NULL ,

[Value] [float] NOT NULL ,

[State] [smallint] NULL

) ON [PRIMARY]

GO

Создание таблицы Shorts

CREATE TABLE [dbo].[Shorts] (

[ID] [int] NOT NULL ,

[MeasureDate] [datetime] NOT NULL ,

[Value] [float] NOT NULL ,

[State] [smallint] NULL

) ON [PRIMARY]

GO

Создание таблицы Shorts_E

CREATE TABLE [dbo].[Shorts_E] (

[ID] [int] NOT NULL ,

[MeasureDate] [datetime] NOT NULL ,

[Value] [float] NOT NULL ,

[State] [smallint] NULL

) ON [PRIMARY]

GO

Создание таблицы USD

CREATE TABLE [dbo].[USD] (

[ID] [int] IDENTITY (1, 1) NOT NULL ,

[Name] [varchar] (50) COLLATE Cyrillic_General_CI_AS NULL ,

[NumUSD] [varchar] (50) COLLATE Cyrillic_General_CI_AS NULL ,

[NumCOMPort] [smallint] NULL ,

[IsWorking] [bit] NOT NULL ,

[TypeCommun] [char] (10) COLLATE Cyrillic_General_CI_AS NULL ,

[Speed] [int] NULL ,

[TypeUSD] [char] (10) COLLATE Cyrillic_General_CI_AS NULL

) ON [PRIMARY]

GO

Создание таблицы UserLimits

CREATE TABLE [dbo].[UserLimits] (

[ID] [int] NOT NULL ,

[ID_User] [int] NOT NULL ,

[CanUse] [bit] NOT NULL ,

[CanEdit] [bit] NOT NULL

) ON [PRIMARY]

GO

ALTER TABLE [dbo].[USD] WITH NOCHECK ADD

CONSTRAINT [PK_USD] PRIMARY KEY CLUSTERED

(

[ID_USPD]

) ON [PRIMARY]

GO

Создание индексов

CREATE UNIQUE CLUSTERED INDEX [IX_ID_Channels] ON [dbo].[Channels]([ID_Channel]) ON [PRIMARY]

GO

CREATE UNIQUE CLUSTERED INDEX [IX_LINES] ON [dbo].[LINES]([ID_Object], [ID_Schetch]) ON [PRIMARY]

GO

CREATE UNIQUE CLUSTERED INDEX [IX_Mains_E] ON [dbo].[Mains_E]([ID_Schetch], [MeasureDate]) ON [PRIMARY]

GO

CREATE UNIQUE CLUSTERED INDEX [IX_ID_DT] ON [dbo].[Shorts]([ID_Channel], [MeasureDate]) ON [PRIMARY]

GO

CREATE UNIQUE CLUSTERED INDEX [IX_Shorts_E] ON [dbo].[Shorts_E]([ID_Schetch], [MeasureDate]) ON [PRIMARY]

GO

ALTER TABLE [dbo].[Channels] WITH NOCHECK ADD

CONSTRAINT [DF_AutoCalcArcInt] DEFAULT (1) FOR [AutoCalcArcInterval]

GO

ALTER TABLE [dbo].[ID_OBJ] WITH NOCHECK ADD

CONSTRAINT [DF_ID_OBJ_IsCommerce] DEFAULT (0) FOR [IsCommerce],

CONSTRAINT [PK_ID_OBJ] PRIMARY KEY NONCLUSTERED

(

[Name]

) ON [PRIMARY]

GO

ALTER TABLE [dbo].[UserLimits] WITH NOCHECK ADD

CONSTRAINT [DF_UserLimits_CanUse] DEFAULT (0) FOR [CanUse],

CONSTRAINT [DF_UserLimits_CanEdit] DEFAULT (0) FOR [CanEdit],

CONSTRAINT [PK_UserLimits] PRIMARY KEY NONCLUSTERED

(

[ID_Object],

[ID_User]

) ON [PRIMARY]

GO

Приложение Б

(обязательное)

Текст программы

unit Main;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, DB, ADODB, Grids, StdCtrls, DBGrids, Menus, TeEngine, Series,

ExtCtrls, TeeProcs, Chart, ComCtrls, ToolWin, ImgList;

type

TForm1 = class(TForm)

dan: TADOTable;

ListBox1: TListBox;

ComboBox1: TComboBox;

ADOConnection2: TADOConnection;

DBGrid1: TDBGrid;

DataSource1: TDataSource;

MainMenu1: TMainMenu;

N1: TMenuItem;

N2: TMenuItem;

N3: TMenuItem;

N4: TMenuItem;

N5: TMenuItem;

Chart1: TChart;

N6: TMenuItem;

N7: TMenuItem;

N8: TMenuItem;

N9: TMenuItem;

N10: TMenuItem;

N11: TMenuItem;

N12: TMenuItem;

ComboBox2: TComboBox;

Button5: TButton;

StringGrid1: TStringGrid;

Button1: TButton;

Series1: TFastLineSeries;

ToolBar1: TToolBar;

ToolButton1: TToolButton;

ToolButton2: TToolButton;

ToolButton3: TToolButton;

ToolButton4: TToolButton;

ToolButton5: TToolButton;

ToolButton6: TToolButton;

ImageList1: TImageList;

Label1: TLabel;

Label2: TLabel;

ADOTable1: TADOTable;

ADOTable2: TADOTable;

ADOTable3: TADOTable;

ADOTable4: TADOTable;

ADOTable5: TADOTable;

ADOTable6: TADOTable;

ADOTable7: TADOTable;

ADOTable8: TADOTable;

ADOTable9: TADOTable;

N13: TMenuItem;

N14: TMenuItem;

N21: TMenuItem;

N31: TMenuItem;

N41: TMenuItem;

N51: TMenuItem;

N61: TMenuItem;

N71: TMenuItem;

N81: TMenuItem;

N91: TMenuItem;

N101: TMenuItem;

otchet: TADOTable;

N15: TMenuItem;

N16: TMenuItem;

N22: TMenuItem;

Button2: TButton;

procedure zapmas;

procedure proverka_dan;

procedure met_niuton;

procedure met_splain;

procedure met_aproksim;

procedure viv_znach;

procedure FormKeyPress(Sender: TObject; var Key: Char);

procedure N5Click(Sender: TObject);

procedure N12Click(Sender: TObject);

procedure N10Click(Sender: TObject);

procedure Button5Click(Sender: TObject);

procedure Button1Click(Sender: TObject);

procedure ToolButton1Click(Sender: TObject);

procedure ToolButton2Click(Sender: TObject);

procedure ToolButton3Click(Sender: TObject);

procedure ToolButton4Click(Sender: TObject);

procedure FormClose(Sender: TObject; var Action: TCloseAction);

procedure FormCreate(Sender: TObject);

procedure N14Click(Sender: TObject);

procedure N21Click(Sender: TObject);

procedure N31Click(Sender: TObject);

procedure N41Click(Sender: TObject);

procedure N51Click(Sender: TObject);

procedure N61Click(Sender: TObject);

procedure N71Click(Sender: TObject);

procedure N81Click(Sender: TObject);

procedure N91Click(Sender: TObject);

procedure N101Click(Sender: TObject);

procedure N15Click(Sender: TObject);

procedure N16Click(Sender: TObject);

procedure N22Click(Sender: TObject);

procedure Button2Click(Sender: TObject);

end;

const

nn=1000000;

const nnn=19;

type

arr=array [0..nnn,0..nnn] of real;

brr=array [0..nnn] of real;

var

xxx,yyy,bbb,cc1,zero,dd1,aa1,bb1:brr;

aaa:arr;

d,r,x1,y1:integer;

fl:boolean;

Form1: TForm1;

a,aa:array [1..2,0..nn-1] of real;

b1,b2:array [0..nn-1] of real;

xx,yy,x:real;

ina,ika,nm,ni,i,j,k,n,kj,h:integer;

apr1:array [1..2,1..3] of extended;

apr2:array [1..3,1..4] of extended;

a1:array [1..2] of real;

a2:array [1..3] of real;

l:real;

s:string;

y,f:Extended;

ff:text;

sss:string;

implementation

uses Unit2, Password, Zastavka, otchet;

{$R *.dfm}

procedure TForm1.viv_znach;

begin

StringGrid1.Cells[0,StringGrid1.RowCount-1]:=FloatToStr(x);

StringGrid1.Cells[1,StringGrid1.RowCount-1]:=FloatToStr(y);

StringGrid1.RowCount:=StringGrid1.RowCount+1;

DBGrid1.Visible:=false;

otchet.Insert;

otchet.Fields.DataSet.Edit;

otchet.Fields[1].AsString:=ComboBox1.Items[ComboBox1.itemindex];

ADOTable5.First;

while ADOTable5.Fields[0].AsString<>ComboBox1.Items[ComboBox1.itemindex] do ADOTable5.Next;

otchet.Fields[2].AsString:=ADOTable5.Fields[2].AsString;

dan.First;

while dan.Fields[0].AsString<>ComboBox1.Items[ComboBox1.itemindex] do dan.Next;

for i:=1 to h-1 do dan.Next;

otchet.Fields[3].AsString:=dan.Fields[1].AsString;

otchet.Fields[4].AsString:='0';

otchet.Fields[5].AsString:=FloatToStr(y);

end;

procedure TForm1.proverka_dan;

begin

i:=0;

for h:=1 to kj do

if a[2,h-1]=0 then inc(i);

if i*100 div kj>=90 then i:=-1;

end;

procedure TForm1.zapmas;

begin

StringGrid1.RowCount:=1;

StringGrid1.Cells[0,0]:='';

StringGrid1.Cells[0,1]:='';

Series1.Clear;

j:=0;

for i:=1 to n do

if FloatToStr(aa[1,i-1])=ComboBox1.Items[ComboBox1.ItemIndex] then begin

a[2,j]:=aa[2,i-1];

a[1,j]:=j;

Series1.AddY(a[2,j]);

inc(j);

end else if j<>0 then break;

kj:=j-1;

end;

function l1(i:integer):Extended;

begin

f:=1;

for j:=ina to ika-1 do if (i<>j) and (a[2,j]<>0) then f:=f*(x-a[1,j]);

//for j:=0 to kj-1 do if (i<>j) and (a[2,j]<>0) then f:=f*(x-a[1,j]);

l1:=f;

end;

function l2(i:integer):Extended;

begin

f:=1;

for j:=ina to ika-1 do if (i<>j) and (a[2,j]<>0) then f:=f*(a[1,i]-a[1,j]);

if f<>0 then l2:=f else l2:=1;

end;

function f1(i:integer):Extended;

begin

f:=1;

for j:=1 to i do if a[1,j-1]<>0 then f:=f*(x-a[1,j-1]);

f1:=f;

end;

function f2(i:integer):real;

begin

if ni=0 then for k:=0 to kj-1 do b1[k]:=a[2,k] else begin

for j:=0 to kj-2 do if a[1,j]<>0 then

if (a[1,j+ni]-a[1,j])<>0 then b2[j]:=(b1[j+1]-b1[j])/(a[1,j+ni]-a[1,j]) else b2[j]:=(b1[j+1]-b1[j]);

for j:=0 to kj-2 do b1[j]:=b2[j];

end;

inc(ni);

f2:=b1[0];

end;

procedure TForm1.met_niuton;

begin

{Ньютон}

zapmas;

proverka_dan;

if i=-1 then begin ShowMessage('Невозможно провести интеррполяцию!');

exit;

end;

for h:=1 to kj do

if a[2,h-1]=0 then begin

x:=a[1,h-1];

y:=0;ni:=0;

for i:=0 to kj-1 do y:=y+f1(i)*f2(i);

viv_znach;

end;

procedure gauss(aaa:arr;bbb:brr;var xxx:brr);

var

i,j,k:byte;

temp:real;

begin

for i:=1 to nnn-1 do begin

temp:=aaa[i,i];

if temp=0 then temp:=1;

for j:=i to nnn-1 do aaa[i,j]:=aaa[i,j]/temp;

bbb[i]:=bbb[i]/temp;

for j:=i+1 to nnn-1 do begin

temp:=aaa[j,i];

for k:=i to nnn-1 do aaa[j,k]:=aaa[j,k]-aaa[i,k]*temp;

bbb[j]:=bbb[j]-bbb[i]*temp end end;

for i:=nnn-1 downto 1 do begin

temp:=bbb[i];

for j:=i+1 to nnn-1 do temp:=temp-aaa[i,j]*xxx[j];

xxx[i]:=temp end;

end;

procedure TForm1.met_splain;

begin

{Сплайны}

zapmas;

{заполнение массива}

for h:=1 to kj do

if a[2,h-1]=0 then begin

x:=a[1,h-1];

if (h=1) or (h=kj) then begin ShowMessage('Нельзя провести интерполяцию сплайнами. Воспользуйтесь другим методом.');exit;end;

if h-1-10<1 then i:=0 else i:=h-1-10;

j:=0;

while i<h-1 do begin aaa[1,j]:=a[1,i];aaa[2,j]:=a[2,i];inc(j);inc(i); end;

fl:=false;

while fl<>true do begin

if a[2,i]=0 then inc(i) else begin aaa[1,j]:=a[1,i];aaa[2,j]:=a[2,i];inc(j);inc(i); end;

if j=20 then fl:=true;

end;

{заполнение X Y}

for i:=0 to nnn do xxx[i]:=aaa[1,i]+1;

for i:=0 to nnn do yyy[i]:=aaa[2,i]+1;

aaa[1,1]:=2*(xxx[2]-xxx[0]);

aaa[1,2]:=xxx[2]-xxx[1];

aaa[nnn-1,nnn-2]:=xxx[nnn-1]-xxx[nnn-2];

aaa[nnn-1,nnn-1]:=2*(xxx[nnn]-xxx[nnn-2]);

for i:=2 to nnn-2 do begin

aaa[i,i]:=xxx[i]-xxx[i-1];

aaa[i,i+1]:=2*(xxx[i+1]-xxx[i-1]);

aaa[i,i+2]:=xxx[i+1]-xxx[i] end;

for i:=1 to nnn-1 do

bbb[i]:=6*((yyy[i+1]-yyy[i])/(xxx[i+1]-xxx[i])-(yyy[i]-yyy[i-1])/(xxx[i]-xxx[i-1]));

cc1:=zero;

gauss(aaa,bbb,cc1);

{b}

for i:=1 to nnn do bb1[i]:=(yyy[i]-yyy[i-1])/(xxx[i]-xxx[i-1])-1/3*(xxx[i]-xxx[i-1])*(cc1[i+1]-cc1[i]);

bb1[0]:=yyy[0]/xxx[0]-1/3*xxx[0]*(cc1[1]-cc1[0]);

{d 1}

for i:=1 to nnn do dd1[i]:=(cc1[i+1]-cc1[i])/(3*(xxx[i]-xxx[i-1]));

dd1[0]:=(cc1[1]-cc1[0])/(3*xxx[0]);

{d 2}

{ for i:=1 to nnn do dd1[i]:=(bb1[i+1]-bb1[i]-2*cc1[i]*(xxx[i]-xxx[i+1]))/(3*(xxx[i]-xxx[i-1])*(xxx[i]-xxx[i-1]));

dd1[0]:=(cc1[1]-cc1[0])/(3*xxx[0]);

{a}

for i:=1 to nnn do aa1[i]:=yyy[i-1];aa1[0]:=0;

l:=x;

for i:=0 to nnn do

if (l>=xxx[i]) and (l<xxx[i+1]) then begin j:=i+1; break; end;

y:=aa1[j]+bb1[j]*(l-xxx[j-1])+cc1[j]*(l-xxx[j-1])*(l-xxx[j-1])+dd1[j]*(l-xxx[j-1])*(l-xxx[j-1])*(l-xxx[j-1]);

viv_znach;

a[1,round(x)]:=x; a[2,round(x)]:=y;

{y:=0;ni:=0;

for i:=0 to kj-1 do y:=y+f1(i)*f2(i);}

end;

procedure TForm1.met_aproksim;

begin

{Апроксимация}

zapmas;

y:=0;

{1}

for i:=1 to 2 do

for j:=1 to 2 do

for k:=0 to n-1 do if a[1,k]<>0 then apr1[i,j]:=apr1[i,j]+exp((i-1)*ln(a[1,k]))*exp((j-1)*ln(a[1,k]));

for i:=1 to 2 do

for k:=0 to n-1 do if a[1,k]<>0 then apr1[i,3]:=apr1[i,3]+exp((i-1)*ln(a[1,k]))*a[2,k];

{Гаусс}

for i:=1 to 2 do begin

for j:=3 downto 1 do apr1[i,j]:=apr1[i,j]/apr1[i,i];

for k:=i+1 to 2 do

for j:=3 downto 1 do

apr1[k,j]:=apr1[k,j]-apr1[k,i]*apr1[i,j];

end;

{Решение Гаусса}

for i:=2 downto 1 do begin

l:=apr1[i,3];

for j:=1 to 2 do l:=l-apr1[i,j]*a1[j];

a1[i]:=l;

end;

{2}

for i:=1 to 3 do

for j:=1 to 3 do

for k:=0 to n-1 do if a[1,k]<>0 then apr2[i,j]:=apr2[i,j]+exp((i-1)*ln(a[1,k]))*exp((j-1)*ln(a[1,k]));

for i:=1 to 3 do

for k:=0 to n-1 do if a[1,k]<>0 then apr2[i,4]:=apr2[i,4]+exp((i-1)*ln(a[1,k]))*a[2,k];

{Гаусс 2}

for i:=1 to 3 do begin

for j:=4 downto 1 do apr2[i,j]:=apr2[i,j]/apr2[i,i];

for k:=i+1 to 3 do

for j:=4 downto 1 do

apr2[k,j]:=apr2[k,j]-apr2[k,i]*apr2[i,j];

end;

{Решение Гаусса 2}

for i:=3 downto 1 do begin

l:=apr2[i,4];

for j:=1 to 3 do l:=l-apr2[i,j]*a2[j];

a2[i]:=l;

end;

procedure TForm1.FormKeyPress(Sender: TObject; var Key: Char);

begin

if key=#27 then close;

end;

procedure TForm1.N5Click(Sender: TObject);

begin

Close;

end;

procedure TForm1.N12Click(Sender: TObject);

begin

Form2.ShowModal;

end;

procedure TForm1.Button5Click(Sender: TObject);

begin

if ComboBox2.ItemIndex=-1 then begin ShowMessage('Выберите метод.');exit; end;

case ComboBox2.ItemIndex of

0:met_niuton;

1:met_lograng;

2:met_splain;

3:met_aproksim;

end;

if StringGrid1.RowCount<>1 then StringGrid1.RowCount:=StringGrid1.RowCount-1;

DBGrid1.Visible:=true;

otchet.Post;

end;

procedure TForm1.Button1Click(Sender: TObject);

begin

x:=kj;

nm:=0;

dan.First;

while dan.Fields[0].AsString<>ComboBox1.Items[ComboBox1.ItemIndex] do begin dan.Next;inc(nm);end;

for i:=1 to StringGrid1.RowCount do begin

j:=strtoint(StringGrid1.Cells[0,i-1]);

if i<>1 then kj:=strtoint(StringGrid1.Cells[0,i-2]) else kj:=0;

for k:=1 to j-kj do begin dan.Next;inc(nm);end;

dan.Fields[2].DataSet.Edit;

dan.Fields[2].AsString:=StringGrid1.Cells[1,i-1];

aa[2,nm]:=dan.Fields[2].AsFloat;

{dan.Post;

dan.Refresh;}

end;

dan.Post;

y:=0;

ADOTable1.First;

for i:=1 to round(x) do y:=y+aa[2,i];

ShowMessage(FloatToStr(y));

while ADOTable1.Fields[0].AsString<>ComboBox1.Items[ComboBox1.ItemIndex] do ADOTable1.Next;

y:=y+ADOTable1.Fields[2].AsFloat;

ADOTable1.Next;

ADOTable1.Fields[2].DataSet.Edit;

ADOTable1.Fields[2].AsFloat:=y;

ADOTable1.Post;

end;

procedure TForm1.ToolButton1Click(Sender: TObject);

begin

met_niuton;

StringGrid1.RowCount:=StringGrid1.RowCount-1;

otchet.Post;

DBGrid1.Visible:=true;

end;

procedure TForm1.ToolButton2Click(Sender: TObject);

begin

met_lograng;

StringGrid1.RowCount:=StringGrid1.RowCount-1;

otchet.Post;

DBGrid1.Visible:=true;

end;

procedure TForm1.ToolButton3Click(Sender: TObject);

begin

met_splain;

StringGrid1.RowCount:=StringGrid1.RowCount-1;

otchet.Post;

DBGrid1.Visible:=true;

end;

procedure TForm1.ToolButton4Click(Sender: TObject);

begin

met_aproksim;

StringGrid1.RowCount:=StringGrid1.RowCount-1;

end;

procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);

begin

Application.Terminate;

end;

procedure TForm1.FormCreate(Sender: TObject);

begin

otchet.Fields.DataSet.Edit;

for i:=0 to otchet.RecordCount-1 do otchet.Delete;

{заставка}

Form4.Show;

Form4.Image1.Picture.LoadFromFile('Z.jpg');

Form4.ProgressBar1.Top:=Screen.Height div 2;

Form4.ProgressBar1.Width:=Form4.Width-10;

Form4.ProgressBar1.Position:=0;

Application.ProcessMessages;

ListBox1.Clear;

ComboBox1.Clear;

n:=dan.RecordCount;

Form4.ProgressBar1.Max:=n;

dan.First;

j:=dan.Fields[0].AsInteger;

ComboBox1.Items.Add(IntToStr(j));

k:=0;

for i:=0 to n-1 do begin

aa[1,i]:=dan.Fields[0].AsFloat;

aa[2,i]:=dan.Fields[2].AsFloat;

Form4.ProgressBar1.Position:=Form4.ProgressBar1.Position+1;

Application.ProcessMessages;

if dan.Fields[0].AsInteger<>j then begin

if k<>0 then ListBox1.Items.Add('У счетчика № '+IntToStr(j)+' - '+IntToStr(k)+' незаполненных значений.');

j:=dan.Fields[0].AsInteger;

ComboBox1.Items.Add(IntToStr(j));

k:=0;

end;

if dan.Fields[2].AsInteger=0 then inc(k);

dan.Next;

if dan.Fields[0].AsInteger>10 then begin Form4.Close;DBGrid1.DataSource:=DataSource1;exit;end;

end;

DBGrid1.DataSource:=DataSource1;

Form4.Close;

end;

procedure TForm1.N14Click(Sender: TObject);

begin

DataSource1.DataSet:=ADOTable1;

end;

procedure TForm1.N21Click(Sender: TObject);

begin

DataSource1.DataSet:=ADOTable2;

end;

procedure TForm1.N31Click(Sender: TObject);

begin

DataSource1.DataSet:=ADOTable3;

end;

procedure TForm1.N41Click(Sender: TObject);

begin

DataSource1.DataSet:=ADOTable4;

end;

procedure TForm1.N51Click(Sender: TObject);

begin

DataSource1.DataSet:=dan;

end;

procedure TForm1.N61Click(Sender: TObject);

begin

DataSource1.DataSet:=ADOTable5;

end;

procedure TForm1.N71Click(Sender: TObject);

begin

DataSource1.DataSet:=ADOTable6;

end;

procedure TForm1.N81Click(Sender: TObject);

begin

DataSource1.DataSet:=ADOTable7;

end;

procedure TForm1.N91Click(Sender: TObject);

begin

DataSource1.DataSet:=ADOTable8;

end;

procedure TForm1.N101Click(Sender: TObject);

begin

DataSource1.DataSet:=ADOTable9;

end;

procedure TForm1.N15Click(Sender: TObject);

begin

end;

procedure TForm1.N16Click(Sender: TObject);

begin

Form5.QuickRep1.Preview;

end;

procedure TForm1.N22Click(Sender: TObject);

begin

Form5.QuickRep2.Preview;

end;

procedure TForm1.Button2Click(Sender: TObject);

begin

Close();

end;

end.

Скачать: Diplomnaya-rabota-gotovaya-v2.0.doc

Категория: Дипломные работы / Дипломные работы по компьютерам

Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

Привет студент

Наверх