Оценка состояния сложных технических объектов
Разработка программного комплекса формирования обобщенной оценки состояния сложных технических объектов на основе обработки событий. Методы мониторинга состояния объектов инфраструктуры. Реализация программного комплекса на языке программирования С++.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 08.10.2018 |
| Размер файла | 6,8 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
РЕФЕРАТ
Выпускная квалификационная работа.
Пояснительная записка: 119 с., 26 рис., 8 табл., 15 источников, 4 приложения.
СОСТОЯНИЕ ТЕХНИЧЕСКОГО ОБЪЕКТА, СЛОЖНЫЙ ТЕХНИЧЕСКИЙ ОБЪЕКТ, ОБОБЩЁННАЯ ОЦЕНКА, ОБРАБОТКА СОБЫТИЙ, ПРОГРАММНЫЙ КОМПЛЕКС, ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ ПРОГРАММИРОВАНИЕ.
Целью работы являются разработка и практическая реализация программного комплекса формирования обобщённой оценки состояния сложных технических объектов на основе обработки событий, разработка новых методов мониторинга состояния объектов инфраструктуры, повышение качества формирования обобщённой оценки состояний объектов мониторинга.
Программный комплекс спроектирован по методологии UML и реализован на языке программирования C++ в среде Qt 5.4.1.
Основное назначение программного комплекса - формирование обобщённой оценки состояния объекта на основе обработки событий. Функциональными возможностями программного комплекса являются: предоставление информационных отчетов и ведение справочной информации, доступ к которым осуществляется в соответствии с правами пользователей.
программный мониторинг технический инфраструктура
СОДЕРЖАНИЕ
ВВЕДЕНИЕ
1. СИСТЕМОТЕХНИЧЕСКАЯ ЧАСТЬ
1.1 Описание процессов мониторинга технического состояния зданий и сооружений
1.2 Обзор аналогов
1.3 Таблицы принятия решений
1.4 Модель анализа Unified Modeling Language
1.4.1 Диаграмма вариантов использования
1.4.2 Сценарий вариантов использования
1.4.3 Диаграмма граничных классов
1.4.4 Диаграмма сущностных классов
1.4.5 Диаграмма классов управления
1.4.6 Логическая структура базы данных
2. РЕАЛИЗАЦИЯ СИСТЕМЫ
2.1 Архитектура и платформа реализации
2.1.1 Операционная система Windows 7
2.2 физическая структура БД
2.3 Расчет комплекса технических свойств(КТС)
2.3.1 Расчет необходимого объема внешней памяти
2.3.2 Расчет необходимого объема оперативной памяти
2.3.3 Расчет времени реакции системы
2.3.4 Требования к техническому и программному обеспечению
2.4 основные интерфейсы
2.5 Описание программной реализации
2.6 Программа и методика описания
2.7 Контрольный пример
2.8 Руководство оператора
2.9 Руководство программиста
2.10 Схема сложного алгоритма
3. ВНЕДРЕНИЕ И АНАЛИЗ ЭФФЕКТИВНОСТИ
3.1 Описание планируемого объекта внедрения
3.2 Бизнес-план
3.2.1 Технико-экономическое обоснование внедрения программного комплекса, формирования обобщённой оценки состояния сложных технических объектов на основе обработки событий
3.2.2 Расчет внедрения программного комплекса, формирования обобщённой оценки состояния сложных технических объектов на основе обработки событий
4. ОРГАНИЦАЦИОННАЯ ДЕЯТЕЛЬНОСТЬ И САМОРАЗВИТИЕ
4.1 Сведения о деятельности возглавляемого микро коллектива
4.2 Перечень публикации
4.3 Перечень участия в конференциях
4.4 Перечень выполненных в период обучения курсовых работ и проектов
4.5 Портфолио
ЗАКЛЮЧЕНИЕ
СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ
ПРИЛОЖЕНИЯ
ВВЕДЕНИЕ
Задача предотвращения чрезвычайных ситуаций и смягчения их последствий для населения, необходимость безопасности жилых зданий и предприятий стали основными предпосылками к созданию Автоматизированных информационных систем предупреждения и ликвидации ЧС.
Зачастую приходится принимать решения в условиях неполной информации об объекте, когда логические процедуры не могут дать однозначного (детерминированного) решения проблемы. В таких случаях оператор-диспетчер привлекает хранящуюся в его памяти информацию о частотах появления тех или иных технологических признаков, возникновения тех или иных ситуаций для принятия вероятностных решений.
В выпускной квалификационной работе планируется реализовать программный комплекс формирования обобщённой оценки состояния сложных технических объектов (жилых зданий, предприятий) на основе обработки событий и таблиц решений.
1. СИСТЕМОТЕХНИЧЕСКАЯ ЧАСТЬ
1.1 Описание процессов мониторинга технического состояния зданий и сооружений
Мониторинг технического состояния зданий и сооружений проводят для [1]:
- контроля технического состояния зданий и сооружений и своевременного принятия мер по устранению возникающих негативных факторов, ведущих к ухудшению этого состояния;
- выявления объектов, на которых произошли изменения напряженно-деформированного состояния несущих конструкций и для которых необходимо обследование их технического состояния;
- обеспечения безопасного функционирования зданий и сооружений за счет своевременного обнаружения на ранней стадии негативного изменения напряженно-деформированного состояния конструкций и грунтов оснований, которые могут повлечь переход объектов в ограниченно работоспособное или в аварийное состояние;
- отслеживания степени и скорости изменения технического состояния объекта и принятия в случае необходимости экстренных мер по предотвращению его обрушения.
При выборе системы наблюдений необходимо учитывать цель проведения мониторинга, а также скорости протекания процессов и их изменение во времени, продолжительность измерений, ошибки измерений, в том числе за счет изменения состояния окружающей среды, а также влияния помех и аномалий природно-техногенного характера. Программу проведения мониторинга согласовывают с заказчиком. В ней, наряду с перечислением видов работ, устанавливают периодичность наблюдений с учетом технического состояния объекта и общую продолжительность мониторинга.
Методика и объем системы наблюдений при мониторинге, включая измерения, должны обеспечивать достоверность и полноту получаемой информации для подготовки исполнителем обоснованного заключения о текущем техническом состоянии объекта (объектов).
В ходе длительных наблюдений и при изменении внешних условий необходимо обеспечить учет изменения условий и компенсационные поправки (температурные, влажностные и т.п.) для измерительных устройств.
Используемые для наблюдений средства измерений и оборудование должны быть сертифицированы, поверены (калиброваны) и аттестованы уполномоченными органами.
В результате проведения каждого этапа мониторинга должна быть получена информация, достаточная для подготовки обоснованного заключения о текущем техническом состоянии здания или сооружения и выдачи краткосрочного прогноза о его состоянии на ближайший период.
Первоначальным этапом мониторинга технического состояния зданий и сооружений (за исключением общего мониторинга технического состояния зданий и сооружений) является обследование технического состояния этих зданий и сооружений. На этом этапе устанавливают категории технического состояния зданий и сооружений, фиксируют дефекты конструкций, за изменением состояния которых (а также за возникновением новых дефектов) будут осуществляться наблюдения при мониторинге.
Общий мониторинг технического состояния зданий и сооружений проводят для выявления объектов, изменение напряженно-деформированного состояния которых требует обследования их технического состояния.
Рисунок 1 - Способ мониторинга и прогнозирования технического состояния зданий и сооружений
При общем мониторинге, как правило, не проводят обследование технического состояния зданий и сооружений в полном объеме, а проводят визуальный осмотр конструкций с целью приблизительной оценки категории технического состояния, измеряют динамические параметры конкретных зданий и сооружений.
Если по результатам приблизительной оценки категория технического состояния здания или сооружения соответствует нормативному или работоспособному техническому состоянию, то повторные измерения динамических параметров проводят через два года.
Если по результатам повторных измерений динамических параметров их изменения не превышают 10%, то следующие измерения проводят еще через два года.
Если по результатам приблизительной оценки категория технического состояния здания или сооружения соответствует ограниченно работоспособному или аварийному состоянию или если при повторном измерении динамических параметров здания или сооружения результаты измерений различаются более чем на 10 %, то техническое состояние такого здания или сооружения подлежит обязательному внеплановому обследованию.
По результатам общего мониторинга технического состояния зданий и сооружений исполнитель составляет заключение по этапу общего мониторинга технического состояния зданий и сооружений и заключения о техническом состоянии каждого здания и сооружения, по которым проводился общий мониторинг технического состояния.
При мониторинге технического состояния зданий и сооружений, категория технического состояния которых соответствует ограниченно работоспособному или аварийному состоянию, контролируют процессы, протекающие в конструкциях зданий и сооружений и грунте до выполнения работ по восстановлению или усилению объектов и во время проведения таких работ.
На каждой стадии мониторинга технического состояния конструкций зданий и сооружений и грунта проводят следующие работы:
- определяют текущие динамические параметры объекта и сравнивают их с параметрами, измеренными на предыдущем этапе;
- фиксируют степень изменения ранее выявленных дефектов и повреждений конструкций объекта и выявляют вновь появившиеся дефекты и повреждения; - проводят повторные измерения деформаций, кренов, прогибов и т.п. и сравнивают их со значениями аналогичных величин, полученными на предыдущем этапе;
- анализируют полученную на данном этапе мониторинга информацию и делают заключение о текущем техническом состоянии объекта.
1.2 Обзор аналогов
Программно-технический комплекс мониторинга состояния и предупреждения ЧС на критически важных и потенциально опасных объектах “БАЗИС” (ПТК СМИС/СМИК объекта)
Назначение
ПТК СМИС/СМИК объекта [2] используется для построения автоматизированных систем мониторинга и предупреждения чрезвычайных ситуаций природного и техногенного характера РСЧС.
ПТК СМИС/СМИК предназначен для:
- получения в режиме реального времени сообщений об инцидентах, авариях, пожарах, свидетельствующих о возможности развития чрезвычайных ситуаций (ЧС) от объектов, оснащенных СМИС;
- своевременного информирования соответствующих дежурно-диспетчерских, оперативно-диспетчерских, аварийно-спасательных, пожарных, надзорных и других служб о получении сообщений об авариях, пожарах, угрозах террористического характера, нарушении работоспособности критически важных для безопасности инженерных систем объектов в соответствии с заключенными соглашениями об обмене информацией;
- контроля развития ситуаций по устранению инцидентов, аварий, пожаров, угроз террористического характера, восстановлению работоспособности критически важных для безопасности инженерных систем на объектах, оснащенных СМИС.
СМИС проектируется в составе раздела “Перечень мероприятий ГОЧС” в соответствии с требованиями ГОСТ Р 22.1.12-2005.
СОСТАВ ПРОГРАММНО-ТЕХНИЧЕСКОГО КОМПЛЕКСА
В ПТК СМИС/СМИК объекта входят:
1. Программно-технический комплекс подсистем сбора данных и передачи сообщений структурированной системы мониторинга и управления инженерными системами зданий и сооружений (ПТК ССП СМИС) включает в себя:
- программный комплекс информационного взаимодействия структурированной системы мониторинга и управления инженерными системами зданий и сооружений объекта (ПК ИВ СМИС объекта) - предназначен для передачи XML-сообщений в органы повседневного управления и отображения информации на АРМ СМИС;
- программный комплекс сервера сопряжения структурированной системы мониторинга и управления инженерными системами зданий и сооружений объекта (ПК СС СМИС объекта) - предназначен для приема сигналов от систем инженерно-технического обеспечения, формирования XML-сообщений и передачи их на сервер СМИС;
- программный комплекс автоматизированного рабочего места структурированной системы мониторинга и управления инженерными системами зданий и сооружений объекта (ПК АРМ СМИС объекта), включающий мониторы оперативного мониторинга и поддержки принятия решения - предназначен для визуализации и редактирования информации об объектах;
- датчики контроля инженерных систем зданий и сооружений объекта, свободно программируемые контроллеры.
2. Программно-технический комплекс подсистемы связи и управления в кризисных ситуациях (ПТК СУКС) включает в себя:
- программируемые ретрансляторы радиосвязи;
- антенно-фидерные устройства (АФУ);
3. Программно-технический комплекс подсистемы мониторинга инженерных (несущих) конструкций (ПТК СМИК) включает в себя:
- программный комплекс сервера системы мониторинга инженерных конструкций (ПК Сервера СМИК) - предназначен для приема и обработки информации о состоянии инженерных (несущих) конструкций объекта, записи и архивированию данных ;
- программный комплекс автоматизированного рабочего места системы мониторинга инженерных конструкций (ПК АРМ СМИК) - предназначен для визуализации и редактирования информации об объектах;
- программный комплекс локального сервера системы мониторинга инженерных конструкций (ПК ЛС СМИК) - предназначен для приема и обработки данных о состоянии инженерных (несущих) конструкций объекта, передачи их на сервер СМИК;
- датчики контроля изменения состояния инженерных (несущих) конструкций (конструктивных элементов) объекта.
ПК АРМ СМИК
Назначение
ПК АРМ СМИК предназначен для отображения информации о состоянии инженерных конструкций зданий, сооружений и опасных природных явлений, сигнализации о нарушении нормальной эксплуатации несущих конструкций, отображения исторических данных показания и состояний датчиков, для обеспечения информационной поддержи принятию решений по предупреждению чрезвычайных ситуаций и решений задач периодического (внеочередного) мониторинга.
Принцип действия
ПК АРМ СМИК (рисунок 2) непрерывно в режиме реального времени получает данные от ПК сервера СМИК о сравнении показаний измерительных устройств с установленными порогами и отображает текущее состояние датчиков в местах их расположения в статичной трёхмерной модели конструкции в виде пиктограмм с цветовым фоном:
- нормальное состояние (зеленый цвет);
- предаварийное состояние (жёлтый цвет);
- аварийное состояние (красный);
- нерабочее состояние датчика или проведение регламентных работ (серый цвет).
В случае выхода показаний датчика за пороговые значения ПК АРМ СМИК выдаёт звуковой сигнал с возможностью его отключения.
Рисунок 2 - Рабочий экран отображения информации о состоянии объекта ПК АРМ СМИК
Диспетчерский программный комплекс “ИСКРа”
Диспетчерский программный комплекс “ИСКРа” [3] (рисунок 3) это пакет программ, предназначенных для централизованного сбора данных из контроллеров серии ТЭКОН-20, информации о процессах энергопотребления и о состоянии технических объектов, ее первичной обработки и архивирования.
Благодаря открытой архитектуре программного комплекса “ИСКРа”, любой отчетный документ может быть сформирован специалистами заказчика как на основе средств Microsoft Office (Word; Excel; Access и др.), так и с помощью других программ, работающих с ODBC-источниками данных (Delphi; Visual FoxPro; Crystal Report и т.п.).
Минимальный комплект программного комплекса:
- База данных (накопление информации);
- Менеджер комплекса (создание конфигурации);
- Рабочее место технолога (формирование табличных отчётов);
- Один из серверов опроса, в зависимости от типа связи (уточняется при заказе).
- Типы серверов опроса в программном комплексе:
- Сбор информации из контроллеров по выделенным и коммутируемым линиям связи (GSM/GPRS, TCP/IP, serial port), по запросу диспетчера или в автоматическом режиме (в соответствии с заданным расписанием опроса контроллеров);
- Дополнение центральной базы данных из баз данных удалённых диспетчерских пунктов;
- Сбор данных из переносных регистраторов информации РИ-197, РИ-97.
Диспетчерский программный комплекс “ИСКРа” предоставляет возможность работы с большими объёмами информации в удобном виде: графики любых параметров и групп параметров, задаваемые пользователем и предустановленные отчетные формы, ведомости утечек, ведомости работы узлов учёта и оборудования.
Рабочее место оператора в программном комплексе “ИСКРа”:
- Анализ информации об энергопотреблении;
- Контроль состояния оборудования объектов, выявление аварийных ситуаций, ведение журнала отказов;
- Визуализация оперативной информации в виде графиков, таблиц, отображение данных на мнемосхемах;
- Звуковое оповещение об аварийных состояниях объектов.
Модуль “Анализ аварийных ситуаций”
Этот модуль позволяет в автоматическом режиме выделить из огромного объёма информации узлы учета с отклонениями в режимах теплопотребления: превышение погрешности расхода и тепла, сосчитанного счетчиком, несоответствие фактического потребления объекта нормативному потреблению тепла и воды, нарушение режима входных параметров по сравнению с температурным графиком.
Даёт возможность предотвратить развитие аварийной ситуации на предварительной стадии, характеризующейся определённым набором параметров. Критерии аварийной ситуации задаёт пользователь, программа выдаёт сводку событий на указанный момент времени. Информация может быть представлена в табличном и графическом виде.
Рисунок 3 - Соблюдение температурного графика поставщиком энергоресурсов Модуля “Анализ аварийных ситуаций”
Дополнительные функции программного комплекса:
Наличие возможности подключения заказных карт города или района, а также мнемонических схем расположения объектов и оборудования позволяет быстро увидеть их адреса, расположение, состояние и т.д.
При поступлении аварийных сигналов из контроллеров комплекс выдает в режиме реального времени звуковые сообщения, а также выполняет соответствующие записи в журнале регистрации отказов.
Работа в локальных сетях позволяет получать информацию широкому кругу заинтересованных пользователей и служб.
Комплекс предоставляет диспетчеру большой объем информации о контролируемом объекте: графики любых параметров или групп параметров, графики параметров оперативного контроля, суточные, месячные отчеты по задаваемым пользователем формам, ведомости утечек, ведомости времени исправной /неисправной работы узлов учета и оборудования.
Время хранения накопленной информации в базе данных, по-умолчанию составляет 1 год, так же устанавливаются пользователем.
Версии программного комплекса:
Базовая
Цена: 9,204 Руб.
- До 4-х контроллеров;
- Любой вид связи на выбор;
- Неограниченное кол-во рабочих мест технолога;
- Бесплатное обновление комплекса в течении 5 лет.
Оптимальная
Цена: 56,463 Руб.
- До 20 контроллеров;
- Неограниченное кол-во рабочих мест технолога;
- Неограниченное кол-во рабочих мест оператора;
- Любой вид связи на выбор;
- Модуль резервного копирования;
- Бесплатное обновление комплекса в течении 5 лет.
Неограниченная
Цена: 101,303 Руб.
- Неограниченное кол-во контроллеров;
- Неограниченное кол-во серверов опроса;
- Неограниченное кол-во рабочих мест технолога;
- Неограниченное кол-во рабочих мест оператора;
- Любой вид связи на выбор;
- Модуль резервного копирования;
- Бесплатное обновление комплекса в течении 5 лет.
Другие системы и комплексы мониторинга состояния технических объектов
Также был проведен анализ других аналогичных информационных систем и программных комплексов мониторинга состояния технических объектов:
- АС единой дежурно-диспетчерской службы (АС ЕДДС) [4];
- АС мониторинга и управления безопасностью и жизнеобеспечением зданий и сооружений (АС МУБЖЗС) [5];
- АС раннего обнаружения чрезвычайных ситуаций и оповещения (АС РОЧСО) [6];
- Комплексная АС управления безопасностью предприятия (КАСУБ) [7];
- АС обеспечения безопасности транспортировки спецгрузов (АСБТ) [8].
Сравнительный анализ АИС и ПК мониторинга состояния технических объектов в таблице 1
Таблица 2 - Сравнительный анализ систем и программных комплексов мониторинга оценки состояний технических объектов
|
Название |
Разграничение прав доступа к системе |
Учет специфики объекта |
Визуализация и мониторинг |
Возможность использовать ресурс повторно |
Цена,руб. |
|
|
ПК формирования обобщённой оценки состояния сложных технических объектов на основе обработки событий |
+ |
+ |
+ |
+ |
15 000 |
|
|
АПК “АСУ-ТАКСИ” |
+ |
- |
- |
- |
55 000 |
|
|
ПК “ARIS SCADA” |
+ |
+ |
+ |
- |
130000 |
|
|
ЦУКС: Мониторинг безопасности КВО |
+ |
+ |
+ |
- |
130 000 |
|
|
АИС ЦУКС |
- |
+ |
+ |
- |
20 000 |
В конечном результате, мною были выполнены следующие пункты:
1. Выполнен анализ предметной области.
2. Найдены и перечислены существующие аналоги.
3. При анализе существующих аналогов, выявлены фактографические характеристики.
4. На основе полученной информации, составлен тезаурус.
5. Сформирована Excel-таблица в АТБД с перечнем фактографических характеристик.
6. Создан макет таблицы, содержащий основную информацию об аналогах.
7. На основе математической модели, сначала на тестовом примере, далее и для предметной области своей ВКР, в среде EXCEL выделена максимальная информативность из начальных информационных кластеров.
Условные выводы:
1. На основе таблицы 1 видно, что лидером по всем найденным объектам можно считать КАСУБ, т.к. она имеет наивысшую оценку.
1.3 Таблицы принятия решений
Для формирования обобщённой оценки технически сложного объекта в разрабатываемом программном комплексе используется разработанный алгоритм на основе таблиц принятия решений.
Таблица принятия решений (таблица решений) [9] -- способ компактного представления модели со сложной логикой. Аналогично условным операторам в языках программирования, они устанавливают связь между условиями и действиями. Но, в отличие от традиционных языков программирования, таблицы решений в простой форме могут представлять связь между множеством независимых условий и действий.
Таблицы принятия решений, как правило, разделяются на четыре квадранта, как показано ниже (рисунок 4).
Рисунок 4 - Схема таблицы принятия решений
В простейшем случае здесь Условия -- список возможных условий, Варианты выполнения условий -- комбинация из выполнения и/или невыполнения условий из этого списка. Действия -- список возможных действий, Необходимость действий -- указание надо или не надо выполнять соответствующее действие для каждой из комбинаций условий. Например, для ситуации “неожиданно погас свет” таблица принятия решений может быть такой:
Рисунок 5 - Таблица принятия решений для ситуации “неожиданно погас свет”
Вариантов выполнения условия может быть не два: да или нет, а несколько, например цвет может быть красным, оранжевым, синим. В более сложных таблицах может применяться нечёткая логика (рисунок 5).
Действия могут быть элементарными или ссылаться на другие таблицы принятия решений. Необходимость выполнения действий может быть неупорядоченной, как в данном примере, или упорядоченной. В последнем случае если при определённой комбинации выполнения условий возможно выполнение нескольких действий, то в таблице решений указывается их приоритет.
1.4 Модель анализа Unified Modeling Language [10]
Эта модель позволит понять, как программный комплекс должен быть спроектирован, какие в нем должны быть части и как они должны взаимодействовать между собой. Основное ее назначение - определить направление реализации функциональности, выявленной на этапе сбора требований и сделать набросок архитектуры системы.
В отличие от создаваемой в дальнейшем модели проектирования, модель анализа является в большей степени концептуальной моделью и только приближает разработчиков к классам реализации. Эта модель не должна иметь возможных противоречий.
1.4.1 Диаграмма вариантов использования
Диаграмма вариантов использования описывает функциональное назначение системы. Она является исходным концептуальным представлением системы и строится с целью:
- определить общие границы и контекст моделируемой предметной области;
- сформировать общие требования к функциональному поведению и интерфейсу системы;
- подготовить исходную документацию для взаимодействия разработчиков и заказчиков - пользователей системы.
В диаграмму вариантов использования входят актанты (actors), варианты использования (use case) и ассоциации (association).
На рисунке 6 изображена разработанная диаграмма вариантов использования. Она содержит 1 актанта. Актант “Специалист по эксплуатации объекта” производит редактирование справочников пользователей, параметров, объектов, состояний; ведёт контроль вводимой информации, ведёт журнал событий и состояний.
Рисунок 6 - Диаграмма вариантов использования
1.4.2 Сценарии вариантов использования
Сценарий - текстовое описание последовательности действий, необходимых для выполнения экземпляра варианта использования. Сценарий пишется по определенному шаблону. При создании сценариев тщательно прорабатывается интерфейс системы, и учитываются отношения между вариантами использования. Для абстрактных вариантов использования, являющихся обобщениями конкретных вариантов, сценарии обычно не пишут.
Ниже приведен сценарий для варианта использования “Вести справочник пользователей”.
Вариант использования: Вести справочник пользователей.
Краткое описание. Позволяет специалисту по эксплуатации объекта вводить, удалять и редактировать информацию о пользователях программного комплекса.
Актант. Специалист по эксплуатации объекта.
Предусловия. Вариант использования “Вход в систему” выполнен с правами специалиста по эксплуатации объекта. На экране - главная форма приложения и одновременно форма оценки состояния объектов с пунктами меню, настроенными на права специалиста по эксплуатации объекта: “Обновить”, “Справочники”, “Журнал”, “Справка”, “Выход”.
Основной поток событий
1. Специалист по эксплуатации объекта выбирает пункт меню “Справочники”.
А1: Обновление состояния объектов.
А2: Просмотр журнала.
А3: Просмотр справки.
А4: Выход.
2. Система выводит на экран форму выбора справочников с пунктами меню “Справочник пользователей”, “Справочник параметров”, “Справочник состояний”, “Справочник объектов” и кнопкой “Закрыть”.
3. Специалист по эксплуатации объекта щёлкает пункт меню “Справочник пользователей”.
А5: Просмотр справочника параметров.
А6: Просмотр справочника состояний.
А7: Просмотр справочника объектов.
4. Система выводит на экран форму просмотра и редактирования справочника пользователей с полями “Логин”, “Пароль”, с кнопками “Добавить запись”, “Удалить запись” и “Сохранить и выйти”.
5. Специалист по эксплуатации объекта вводит информацию о новом пользователе в поля и щёлкает кнопку “Добавить запись” пользователей.
А8: Удалить запись.
5. Система выводит сообщение об успешном добавлении записей в справочник пользователей, если были заполнены все поля на форме и информация отвечала критериям добавления записи.
6. Специалист по эксплуатации объекта просматривает сообщение и щёлкает кнопку “ОК”. Затем щёлкает кнопку “Сохранить и выйти”, затем щёлкает кнопку “Закрыть”. Система выводит на экран главную форму приложения с пунктами меню, настроенными на права специалиста по эксплуатации объекта. Вариант использования завершается успешно.
Альтернативы
А1: Обновление состояния объектов.
А1.1: Специалист по эксплуатации объекта щёлкает кнопку “Обновить”.
А1.2: Система заново прочитывает соответствующую таблицу базы данных и обновляет состояния объектов на форме. Вариант использования завершается.
А2: Просмотр журнала.
А2.1: Специалист по эксплуатации объекта выбирает пункт меню “Журнал”.
А2.2: Система выводит на экран форму статистики событий и состояний с кнопкой “Закрыть”.
А2.3: Специалист по эксплуатации объекта просматривает отчёт и щёлкает кнопку “Закрыть”.
А2.4: Система закрывает форму статистики событий и состояний и выводит на экран главное окно приложения с пунктами меню, настроенными на права специалиста по эксплуатации объекта. Вариант использования завершается.
А3: Просмотр справки.
А3.1: Специалист по эксплуатации объекта выбирает пункт меню “Справка”.
А3.2: Система выводит на экран форму справки по системе с кнопкой “Закрыть”.
А3.3: Специалист по эксплуатации объекта просматривает справку и щёлкает кнопку “Закрыть”.
А3.4: Система закрывает форму “Справка по системе” и выводит на экран главное окно приложения с пунктами меню, настроенными на права специалиста по эксплуатации объекта. Вариант использования завершается.
А4: Выход.
А4.1: Специалист по эксплуатации объекта выбирает пункт меню “Выход”.
А4.2: Система закрывает окно программы и выводит на экран главное окно операционной системы. Вариант использования завершается.
А5: Просмотр справочника параметров.
А5.1: Аналогично варианту использования “Вести справочник пользователей”. Вариант использования завершается.
А6: Просмотр справочника состояний.
А6.1: Аналогично варианту использования “Вести справочник пользователей”. Вариант использования завершается.
А7: Просмотр справочника объектов.
А7.1: Аналогично варианту использования “Вести справочник пользователей”. Вариант использования завершается.
А8: Удалить запись.
А8.1 Специалист по эксплуатации объекта щёлкает кнопку “Удалить запись”.
А8.2 Система выдаёт подтверждающее сообщение об удалении выбранной строки в справочнике с кнопками “Yes” и “No”.
А8.3 Специалист по эксплуатации объекта щёлкает кнопку “Yes”.
А8.4 Система удаляет выбранную строку справочника. Вариант использования завершается.
1.4.3 Диаграмма граничных классов
Диаграмма граничных классов -- диаграмма, демонстрирующая классы взаимодействия системы с внешним окружением и их основные функции.
Классы по своей роли в системе делятся на группы. Сам по себе язык UML жестко не оговаривает эти группы, оставляя группировку на усмотрение разработчиков. На основе опыта, накопленного при создании автоматизированных систем, целесообразно выделить группу граничных (boundary) классов. Объекты этих классов реализуют интерфейсы системы с внешней средой и различными пользователями (не следует их путать с внутренними интерфейсами взаимодействия классов).
Диаграмма граничных классов разработанного программного комплекса изображена на рисунке 7.
Рисунок 7 - Диаграмма граничных классов
1.4.4 Диаграмма сущностных классов
Сущностные (entity) классы: объекты этих классов представляют собой блоки длительно хранимой информации, используемые для организации баз данных и знаний, файловых систем хранения данных различной логической структуры; в основном в этих классах развит атрибутный раздел, однако имеется небольшое число операций контроля ограничений целостности, как стандартных, так и специфичных для данной предметной области.
Диаграмма сущностных классов разработанного программного комплекса изображена на рисунке 8.
1.4.5 Диаграмма классов управления
Классы управления (control): объекты этих классов являются активными, берущими на себя управление и организацию вычислительных процессов; чаще всего это стандартные компоненты операционных систем и систем управления базами данных (СУБД), таймеры, координаторы и т.п.
Диаграмма классов управления разработанного программного комплекса изображена на рисунке 9.
Рисунок 8 - Диаграмма сущностных классов
1.1.1.
Рисунок 9 - Диаграмма классов управления
1.1.1. 1.4.6 Логическая структура базы данных
Задача логической модели данных заключается в описании объектов данных предметной области и взаимосвязей между ними. При разработке модели, зачастую, приходится сталкиваться с сущностями, уникальность которых зависит от значений атрибута внешнего ключа. Для этих сущностей (для уникального определения каждой сущности) внешний ключ должен быть частью первичного ключа дочернего объекта.
Дочерняя сущность, уникальность которой зависит от атрибута внешнего ключа, называется зависимой сущностью.
Существует ряд правил организации структур данных, называемых нормальными формами. Нормализация - процесс приведения модели структуры данных к некоторой нормальной форме. Как правило, используется третья нормальная форма. Она обеспечивает эффективное и не избыточное хранение данных. В таблице 5 приведены требования, которым должна удовлетворять структура БД для того, чтобы быть в одной из первых трех нормальных форм. В процессе нормализации анализируется структура БД, и выявляются элементы, противоречащие определенной нормальной форме.
Таблица 3 - Требования нормализации
|
Нормальная форма |
Требования нормализации |
|
|
1НФ |
БД находится в 1НФ тогда и только тогда, когда поля всех таблиц содержат только атомарные значения и в таблицах нет полностью повторяющихся строк. |
|
|
2НФ |
БД находится в 2НФ тогда и только тогда, когда значение любого не ключевого поля зависит от всего первичного ключа. Так же она должна находиться в 1НФ. |
|
|
3НФ |
БД находится в 3НФ тогда и только тогда, когда значение любого не ключевого поля зависит только от значения первичного ключа, но не от значения другого не ключевого поля. Так же она должна находиться во 2НФ. |
В результате анализа предметной области и, исходя из поставленных задачей, для функционирования ИС было выделено 5 сущностей:
1) Пользователи - предназначена для хранения данных о пользователях программного комплекса.
Атрибуты: ID пользователя, Логин, Пароль, Роль.
2) Параметры - предназначена для хранения данных о параметрах.
Атрибуты: ID параметра, Параметр, Размерность.
3) Состояния - предназначена для хранения данных о состояниях.
Атрибуты: ID состояния, Состояние, Условие.
4) Журнал - сводная сущность для просмотра статистики событий и состояний.
Атрибуты: ID события, ID параметра (FK), ID состояния (FK), ID объекта (FK), Дата, Время, Значение.
5) Объекты - предназначена для хранения данных об объектах.
Атрибуты: ID объекта, Объект, Адрес.
Логическая модель данных проектируемой ИС была разработана в Erwin Data Modeler r7 (рисунок 10). В ней учтены все необходимые для функционирования программного комплекса сущности и их атрибуты, а также проставлены связи между ними.
Рисунок 10 - Логическая структура базы данных
2. РЕАЛИЗАЦИЯ СИСТЕМЫ
2.1 Архитектура и платформа реализации
2.1.1 Операционная система Windows 7
Windows 7 под кодовыми наименованиями Blackcomb и Vienna - операционная система семейства Windows NT, следующая за Windows Vista. В линейке Windows NT система носит номер версии 6.1 (Windows 2000 - 5.0, Windows XP - 5.1, Windows Server 2003 - 5.2, Windows Vista и Windows Server 2008 - 6.0). Серверной версией является Windows Server 2008 R2, версией для интегрированных систем - Windows Embedded Standard 2011 (Quebec), мобильной - Windows Embedded Compact 2011 (Chelan, Windows CE 7.0) [11].
Операционная система поступила в продажу 25 октября 2009 года, меньше чем через три года после выпуска предыдущей операционной системы, Windows Vista. Хотя изначально операционная система должна была поступить в продажу уже 31 августа 2009 года. Партнёрам и клиентам, обладающим лицензией Volume Licensing, доступ к RTM был предоставлен 24 июля 2009 года. Финальная нелицензионная версия (копия с дисков, которые потом пошли в продажу) была доступна всем с первых чисел августа 2009 года.
В состав Windows 7 вошли как некоторые разработки, исключённые из Windows Vista, так и новшества в интерфейсе и встроенных программах. Из состава Windows 7 были исключены игры Incball, Ultimate Extras; приложения, имеющие аналоги в Windows Live (Почта Windows, Календарь Windows и пр.), технология Windows Agent, Windows Meeting Space; из меню "Пуск" исчезла возможность вернуться к классическому меню и Версии Windows 7.
2.1.2 Библиотека Qt 5.4.1
Qt -- кросс платформенный инструментарий разработки ПО на языке программирования C++. Qt позволяет запускать написанное с его помощью ПО в большинстве современных операционных систем путем простой компиляции программы для каждой ОС без изменения исходного кода. Включает в себя все основные классы, которые могут потребоваться при разработке прикладного программного обеспечения, начиная от элементов графического интерфейса и заканчивая классами для работы с сетью, базами данных и XML. Qt является полностью объектно-ориентированным, легко расширяемым и поддерживающим технику компонентного программирования [12].
2.1.3 СУБД Microsoft Office Access 2003
Microsoft Office Access -- реляционная СУБД корпорации Microsoft входящая в пакет программ MS Office. Access включает связанные запросы, связь с внешними таблицами и базами данных. Благодаря встроенному языку VBA, в Access можно писать приложения, работающие с базами данных [13].
2.1.4 Язык программирования C++
C++ -- компилируемый статически типизированный язык программирования общего назначения. Поддерживает такие парадигмы программирования как процедурное программирование, объектно-ориентированное программирование, обобщённое программирование, обеспечивает модульность, раздельную компиляцию, обработку исключений, абстракцию данных, объявление типов (классов) объектов, виртуальные функции. Стандартная библиотека включает, в том числе, общеупотребительные контейнеры и алгоритмы. C++ сочетает свойства как высокоуровневых, так и низкоуровневых языков. В сравнении с его предшественником -- языком C -- наибольшее внимание уделено поддержке объектно-ориентированного и обобщённого программирования. C++ широко используется для разработки программного обеспечения, являясь одним из самых популярных языков программирования. Область его применения включает создание операционных систем, разнообразных прикладных программ, драйверов устройств, приложений для встраиваемых систем, высокопроизводительных серверов, а также развлекательных приложений (игр). Существует множество реализаций языка C++, как бесплатных, так и коммерческих и для различных платформ. Например, на платформе x86 это GCC, Visual C++, Intel C++ Compiler, Embarcadero (Borland) C++ Builder и другие. C++ оказал огромное влияние на другие языки программирования, в первую очередь на Java и C#. Синтаксис C++ унаследован от языка C. Одним из принципов разработки было сохранение совместимости с C. Тем не менее, C++ не является в строгом смысле надмножеством C; множество программ, которые могут одинаково успешно транслироваться как компиляторами C, так и компиляторами C++, довольно велико, но не включает все возможные программы на C [14].
2.2 Физическая структура базы данных
Модель сущность-связь (ER-модель) (англ. entity-relationship model, ERM) [15] -- модель данных, позволяющая описывать концептуальные схемы предметной области.
ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями.
Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.).
ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма сущность-связь (ER-диаграмма) (англ. entity-relationship diagram, ERD).
Понятия ER-модель и ER-диаграмма часто ошибочно не различают, хотя для визуализации ER-моделей предложены и другие графические нотации.
ER-модель разработанного программного комплекса изображена на рисунке 11.
Таблица 4 - Сущности базы данных
|
Сущность на логическом уровне |
Таблица на физическом уровне |
|
|
Пользователь |
USER |
|
|
Параметр |
PARAMETER |
|
|
Объект |
OBJECT |
|
|
Характеристика состояния |
STATES |
|
|
Параметр/состояние |
PARAMETER/STATE |
Рисунок 11 - Физическая ER-модель данных
1.1. 2.3 Расчет комплекса технических свойств (КТС)
Для оценки параметров комплекса технических средств, производится расчет требуемых ресурсов внешней и оперативной памяти и расчет времени реакции системы.
2.3.1 Расчет необходимого объема внешней памяти
Расчет объема требуемой внешней памяти происходит по формуле (1):
(1)
где - объём внешней памяти, занимаемый операционной системой, Мб;
- объём внешней памяти, занимаемый СУБД, Мб;
- объём внешней памяти, занимаемый данными, необходимыми для работы системы, Мб;
- объём внешней памяти, занимаемый программными модулями, Мб;
- объём внешней памяти, необходимый для дополнительно необходимого ПО.
- общий объем внешней памяти, Гбайт.
Расчет необходимого объема внешней памяти:
- объем внешней памяти, по паспорту для операционной системы Windows 7 64-бит - 20 Гб;
- объем внешней памяти, требуемый для хранения файлов СУБД по паспорту для Access - 2 Гб.
В таблице 3 показан расчёт максимального объема базы данных.
Таблица 5 - Расчет объёма базы данных
|
Таблица базы данных |
Размер записи, байт |
Макс. кол-во записей |
Размер индекса, Кбайт |
Всего, Кбайт |
|
|
USER |
255 |
15 |
200 |
4399 |
|
|
Окончание таблицы 7 |
|||||
|
PARAMETER |
255 |
20 |
230 |
5865 |
|
|
FEATURE STATE |
255 |
100 |
9240 |
34740 |
|
|
OBJECT |
255 |
20 |
396 |
5496 |
|
|
PARAMETER/STATE |
255 |
1000 |
284 |
255284 |
|
|
Итого: |
304875 |
= 0,3 Гб.
= 0,013 Гб.
VВП = VОС (20) + VСУБД (2) + Vданных (0,3) + Vпрограммы (0.013)= 22,313 Гб
2.3.2 Расчет необходимого объема оперативной памяти
Для расчета ОЗУ воспользуемся формулой (2):
, (2)
где VОП - общий объем оперативной памяти, Мбайт;
VОС - объем оперативной памяти, требуемый для установки операционной системы, Мбайт;
VСУБД - объем оперативной памяти, требуемый для установки СУБД, Мбайт;
VДанных - объем оперативной памяти, требуемый для хранения записей базы данных и результатов выполнения функций, Мбайт;
VПрограммы - объем оперативной памяти, необходимой для хранения текстов и библиотек приложений, Мбайт.
Расчет необходимого объема оперативной памяти:
VОС - по паспорту для операционной системы Windows 7 64 бит - 4096 Мб;
VСУБД - по паспорту для Access - 256 Мб:
VДанных - 80 Мб;
VПрограммы - 40 Мб.
Расчет VДанных произведем на наихудший случай, запрос на максимальное количество таблиц БД. Наиболее сложным запросом является запрос на расчет и формирование отчета “Журнал”, т.к. требует для своего формирования использования наибольшего числа таблиц БД, а именно 4 из 5 возможных. VДанных рассчитывается по таблице 8.
Таблица 6 - Расчет объема буфера оперативной памяти
|
Таблица БД |
Размер записи, байт |
Макс. кол-во записей |
Размер индекса, Кбайт |
Всего, Кбайт |
|
|
USER |
255 |
15 |
2500 |
6325 |
|
|
PARAMETER |
255 |
20 |
2300 |
7400 |
|
|
FEATURE STATE |
255 |
100 |
9240 |
34740 |
|
|
OBJECT |
255 |
20 |
3960 |
9060 |
|
|
PARAMETER/STATE |
255 |
1000 |
2840 |
257840 |
|
|
PARAMETER |
255 |
20 |
2350 |
7450 |
|
|
Итого: |
322815 |
Суммарный объем ОЗУ, необходимый для функционирования системы:
VОП = VОС (4096) + VСУБД (256) + Vданных (80) + Vпрограммы (40) = 4472 Мб
2.3.3 Расчет времени реакции системы
Расчет времени реакции системы должен дать оценку быстродействия системы. Временем реакции системы по какой-либо функции называется время от момента начала запроса на выполнение этой функции от внешнего источника запросов до момента окончания формирования результата по данной функции. Время реакции системы рассчитывается на наихудший случай для самого сложного запроса. Самым сложным запросом является расчет и формирование отчета “Журнал”.
teeoda - время на ввод входных данных запроса; kee - коэффициент ошибок при вводе, для расчетов можно принять равным 1.5; Lсимe - количество символов, вводимых в качестве исходных данных запроса.
Так, как оператор выбирает информацию из списка, будем считать, что Lсимe = 2 (открытие списка и выбор из списка).
tсимe - время ввода одного символа, при ручном вводе с клавиатуры в некоторую экранную форму можно принять в среднем равным 2 с;
tсчитывания - время, затрачиваемое на считывание физических блоков при работе с накопителем;
Nбл - количество считываемых физических блоков, зависит от количества обрабатываемых таблиц (файлов) и объема таблиц (файлов);
tпоз = 0,005 сек - время позиционирования головок дискового накопителя;
tсч.бл = 0,002 сек - время считывания физического блока в дисковом накопителе;
tвычисления - время, затрачиваемое процессором на обработку информации с учетом выполнения циклов;
Nопер = 1100 - количество операций высокого уровня, необходимых для формирования результата;
K1 - среднее количество тактов машинных команд на одну операцию, для большинства случаев можно принять К1 = 60;
f = 1400*106 - тактовая частота процессора, Гц;
Vmaбл = 104600 байт - средний объем таблицы, байт;
Nmaбл = 3 - количество таблиц, обрабатываемых в запросе;
Ублока= 512 байт - объем физического блока носителя, байт;
tвывода - время на вывод результата на устройство вывода или отображения, для принтера оценивается отдельно. Для дисплея можно принять 0.5 с. (зависит от видеокарты и дисплея).
Полученное время реакции системы соответствует нормам времени для диалогового режима (до 30 с).
2.3.4 Требования к техническому и программному обеспечению
Приведем минимальные требования к техническому и программному обеспечению, исходя из расчетов объемов внешней и оперативной памяти, приведенных в п. 2.7. Требования к процессору определяются требованиями ОС.
Минимальные требования к рабочей станции:
- процессор класса Pentium с тактовой частотой 1,6 ГГц и выше;
- объем оперативной памяти не менее 4 Гб;
- объем свободного дискового пространства не менее 22,1 Гб;
- тип операционной системы - Windows 7 64 бит (или вышедшие следом);
- манипулятор типа “мышь”;
- монитор с разрешением 1280x1024.
Программный комплекс должен удовлетворять следующим требованиям:
- функциональный характер -- требования к поведению системы;
- пользовательские требования;
- функциональные требования.
- нефункциональный характер - требования к характеру поведения системы;
- системные требования и ограничения - определения элементарных операций, которые должна иметь система, а также различных условий, которым она может удовлетворять. К системным требованиям и ограничениям относятся:
- ограничения на программные интерфейсы, в том числе к внешним системам;
- требования к атрибутам качества;
- требования к применяемому оборудованию и ПО.
- требования к документированию;
- требования к дизайну и удобности интерфейсов;
- требования к безопасности и надёжности;
- требования к показателям назначения (производительность, устойчивость к сбоям и т.п.);
- требования к эксплуатации и персоналу;
- прочие требования и ограничения (внешние воздействия, мобильность, автономность и т.п.).
2.4 Основные интерфейсы
На рисунке 11 изображён интерфейс авторизации пользователя. На данном интерфейсе расположены два текстовых поля ввода для логина и пароля и кнопки “Войти” для входа в программный комплекс, “Очистить” для очистки полей ввода и “Выход” для выхода из комплекса.
Рисунок 12 - Интерфейс авторизации
На рисунке 12 изображён интерфейс мониторинга объектов. Он позволяет просматривать состояние объектов, открыть справочники, журнал и справку. На данном интерфейсе расположены кнопки “Справочники”, “Журнал”, “Справка” и кнопка “Выход”, для выхода на авторизацию.
Рисунок 13 - Интерфейс мониторинга объектов
На рисунке 13 изображён интерфейс просмотра журнала. Он позволяет просматривать журнал событий и параметров. На данном интерфейсе расположены таблица и кнопка “Закрыть”.
Рисунок 14 - Интерфейс просмотра журнала
На рисунке 14 изображён интерфейс выбора справочников. Он позволяет выбрать нужный справочник. На данном интерфейсе расположены кнопки “Справочник пользователей”, “Справочник параметров”, “Справочник состояний” и “Закрыть”.
Рисунок 15 - Интерфейс выбора справочников
На рисунке 15 изображён интерфейс ведения справочника пользователей. Он позволяет добавлять, удалять и редактировать записи в справочнике. На данном интерфейсе расположены таблица и кнопки “Добавить запись”, “Удалить запись” и “Сохранить и выйти”.
Рисунок 16 - Интерфейс ведения справочника пользователей
На рисунке 16 изображён интерфейс ведения справочника параметров. Он позволяет добавлять, удалять и редактировать записи в справочнике. На данном интерфейсе расположены таблица и кнопки “Добавить запись”, “Удалить запись” и “Сохранить и выйти”.
Рисунок 17 - Интерфейс ведения справочника параметров
На рисунке 17 изображён интерфейс ведения справочника состояний. Он позволяет добавлять, удалять и редактировать записи в справочнике. На данном интерфейсе расположены таблица и кнопки “Добавить запись”, “Удалить запись” и “Сохранить и выйти”.
На рисунке 18 изображён интерфейс ведения справочника объектов. Он позволяет добавлять, удалять и редактировать записи в справочнике. На данном интерфейсе расположены таблица и кнопки “Добавить запись”, “Удалить запись” и “Сохранить и выйти”.
Рисунок 18 - Интерфейс ведения справочника параметров
Рисунок 19 - Интерфейс ведения справочника параметров
На рисунке 19 изображён интерфейс справки о системе. Он позволяет выдать информацию о целях и задачах программного комплекса. На данном интерфейсе расположены таблица и кнопка “Закрыть”.
Рисунок 20 - Интерфейс справки о программе
2.5 Описание программной реализации
Подобные документы
Разработка аппаратно-программного комплекса для осуществления идентификации объектов управления на основе вещественного интерполяционного метода. Анализ работоспособности аппаратно-программного комплекса, пример идентификации объекта управления.
магистерская работа [2,2 M], добавлен 11.11.2013Исследование принципов объектно-ориентированного программирования на базе языка программирования С++. Разработка программного комплекса для ведения учёта памятников города. Описание процессов сортировки, поиска, формирования статистики по памятникам.
курсовая работа [782,4 K], добавлен 26.05.2014Разработка программного обеспечения для автоматизированной системы калибровки и поверки комплекса технических средств ПАДК "Луг-1". Аналитический обзор аналогов. Проектирование пользовательского интерфейса. Средства разработки программного обеспечения.
дипломная работа [1,4 M], добавлен 17.12.2014Разработка для ОАО "КБ "Луч" технологического программного обеспечения комплекса технических средств радиосвязи С-диапазона. Предназначение комплекса для контроля и управления аппаратурой посредством внешних интерфейсов через порты Ethernet и COM.
презентация [577,1 K], добавлен 14.07.2012Проектирование программного комплекса на языке С++ с использованием принципов объектно-ориентированного программирования. Разработка разных меню, помогающих пользователю работать с программой. Описание процесса формирования статистики по памятникам.
курсовая работа [799,9 K], добавлен 01.12.2016Основы метода Монте-Карло и его применение. Разработка и тестирование программного модуля для ПК BRAND, позволяющего строить двумерные и трехмерные изображения для сложных геометрических объектов для обеспечения контроля за качеством сборки конструкций.
дипломная работа [5,2 M], добавлен 10.10.2015Разработка и реализация программы расчета заданных функций на языке программирования VBA. Математическая модель, параметры и характеристики задачи, критерии оценки эффективности созданного модуля. Разработка алгоритма и тестирование программного модуля.
курсовая работа [488,7 K], добавлен 08.09.2010Преимущества выбора программного комплекса АВК-5. Создание списка строек, учетные реквизиты и значения ряда новых параметров. Способ расчета прибыли. Создание объектов строительства, проектирование локальной сметы. Заполнение графы "Виды работ и затрат".
дипломная работа [2,9 M], добавлен 14.08.2013Проектирование серверного компонента, исполняющегося на узле кластера EMC Centera. Протокол взаимодействия компонентов, способный восстанавливаться после разрыва соединения между компонентами. Графический интерфейс пользователя для программного комплекса.
дипломная работа [1,1 M], добавлен 18.07.2014Разработка программного комплекса и описание алгоритма. Разработка пользовательского интерфейса. Анализ тестовых испытаний программного блока. Защита пользователей от воздействия на них опасных и вредных факторов. Режимы работы программного комплекса.
дипломная работа [1,7 M], добавлен 14.03.2013
