Разработка информационной подсистемы тестирования встроенного программного обеспечения PLC-модемов для ЗАО "КИЭП "Энергомера"

Размещено на http://www.allbest.ru/

Введение

1. Предпроектное обследование ЗАО "КИЭП "Энергомера", г. Ставрополь. Формулировка задач проектирования

1.1 Постановка задачи предпроектного обследования

1.1.1 Объект и методы проведения предпроектного обследования

1.1.2 Программа проведения обследования

1.1.3 План-график выполнения работ обследования

1.2 Характеристика предприятия ЗАО "КИЭП "Энергомера"

1.2.1 Общая характеристика предприятия

1.2.2 Организационная структура предприятия

1.2.3 Организационно-управленческая модель

1.3 Технические и программные средства ЭИВТ предприятия

1.3.1 Задачи, решаемые с использованием средств ЭИВТ

1.3.2 Технические средства

1.3.3 Программные средства

1.3.4 Локальная сеть предприятия

1.3.5 Организация доступа к мировым информационным сетям

1.3.6 Обеспечение информационной безопасности, защита информации

1.3.7 Информационные базы и информационные потоки

1.3.8 Проблемные ситуации и способы их решения

1.3.9 Выбор проблемной ситуации для решения

1.4 Формулировка задач проектирования

1.4.1 Общие сведения о проекте

1.4.2 Назначение, цели создания информационной подсистемы

1.4.3 Характеристика объекта автоматизации

1.4.4 Требования к подсистеме

1.4.5 Состав и содержание работ по созданию подсистемы

1.4.6 Порядок контроля приемки подсистемы

1.4.7 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу подсистемы в действие

1.4.8 Требования к документированию

1.4.9 Источники разработки

Выводы

2. Разработка информационной подсистемы PLC-Tester

2.1 Обоснование выбора программного обеспечения

2.2 Проектирование и разработка БД

2.2.1 Определение сущностей

2.2.2 Определение зависимостей между сущностями

2.2.3 Определение атрибутов сущностей, создание первичных и внешних ключей

2.2.4 Создание физической модели данных

2.2.5 Разработка хранимых процедур

2.2.6 Создание пользователей и распределение привилегий

2.3 Проектирование и разработка модуля тестирования и сбора данных

2.3.1 Проектирование модуля

2.3.2 Разработка модуля TNNCL.dll

2.3.3 Разработка модуля TAT.dll

2.3.4 Разработка модуля PLCTester.exe

2.4 Разработка web-приложения

Выводы

3. Информационная подсистема PLC-Tester

3.1 Общие сведения о программном продукте

3.2 Функциональное назначение программного продукта

3.3 Описание логической структуры программного продукта

3.4 Требования к техническому обеспечению

3.4.1 Общие требования

3.4.2 Требования к центральному процессору

3.4.3 Требования к оперативному запоминающему устройству

3.4.4 Требования к наличию свободного места на жестком диске

3.4.5 Требования к монитору

3.4.6 Прочие требования

3.5 Вызов программы

3.5.1 Установка ПО

3.5.2 Запуск программы

3.6 Входные данные

3.7 Выходные данные

3.8 Описание тестовых прогонов

3.8.1 Общие сведения

3.8.2 Тестирование модуля PLCTester

3.8.3 Тестирование web-приложения

Выводы

4. Технико-экономическое обоснование проекта

4.1 Краткая характеристика проекта

4.2 Трудоемкость выполняемых работ

4.3 Расчет себестоимости информационной подсистемы

4.4 Оценка экономической эффективности внедрения программного продукта

4.5 Основные технико-экономические показатели проекта

Выводы

5. Безопасность и экологичность проекта

5.1 Общая характеристика опасных, вредных факторов на рабочем месте оператора информационной подсистемы

5.2 Обеспечение безопасности на рабочем месте оператора информационной подсистемы

5.3 Расчет защитного зануления на отключающую способность

Выводы

Заключение

Библиографический список

Приложение

ВВЕДЕНИЕ

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

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

Одной из основных задач АСКУЭ является автоматизированный процесс сбора данных со счетчиков электроэнергии, который может осуществляться по различным каналам связи и технологиям (RS-232, RS-485, Ethernet, GSM, GPRS, PLC и др.), схема АСКУЭ представлена в приложении А. Технология PLC (средой передачи являются линии электропередачи) обладает рядом преимуществ: нет необходимости прокладывать и обслуживать дополнительную кабельную систему (например, как при использовании технологии Ethernet); нет необходимости платить за передачу данных сторонним организациям (например, как при использовании технологий GPRS и GSM).

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

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

В первом разделе пояснительной записки описаны: общая структура предприятия, задачи предприятия, структура ЛВС предприятия, информационные системы предприятия, выявлены проблемные ситуации и выбрана одна для решения.

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

В третьем разделе описана уже разработанная информационная подсистема.

В четвертом разделе представлено обоснование экономической эффективности проекта.

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

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

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

1. Предпроектное обследование ЗАО "КИЭП "Энергомера", г. Ставрополь. Формулировка задач проектирования

1.1 Постановка задачи предпроектного обследования

1.1.1 Объект и методы проведения предпроектного обследования

Основными объектами предпроектного обследования являются:

- характеристика предприятия;

- структура предприятия;

- информационные системы, функционирующие на предприятии;

- программные и технические средства, используемые;

- корпоративная сеть предприятия, и её особенности;

- обеспечение информационной безопасности;

- информационные потоки и базы предприятия;

- проблемные ситуации, имеющиеся на предприятии;

- возможные способы решения проблемных ситуаций.

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

- функции, выполняемые системой;

- структура системы;

- пользователи системы;

- место системы в структуре предприятия;

- производственные процессы, связанные системой;

- проблемные ситуации, связанные с функционированием системы.

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

- личные наблюдения;

- анкетирование и опросы;

- беседы и консультации (как с начальниками отделов, так и с рядовым сотрудниками);

- анализ системы изнутри (изучение исходных кодов и прочее).

1.1.2 Программа проведения обследования

Обследование предприятия проводится по заранее разработанной программе, составляемой по форме, представленной в таблице 1.1.

Таблица 1.1 - Программа проведения обследования предприятия

Наименование вопроса	Источник информации	Получатель инфор
Общая характеристика	Начальник отдела развития	Студент Саркисов С.А.
Организационная структура	Директор предприятия	Студент Саркисов С.А.
Организационно-управленческая модель	Директор предприятия	Студент Саркисов С.А.
Задачи, решаемые с использованием средств ЭИВТ	Начальник ОКПО	Студент Саркисов С.А.
Технические средства	Начальник отдела IT	Студент Саркисов С.А.
Программные средства	Начальник отдела IT	Студент Саркисов С.А.
Локальная сеть	Начальник отдела IT	Студент Саркисов С.А.
Организация доступа к мировым информационным сетям	Начальник отдела IT	Студент Саркисов С.А.
Обеспечение информационной безопасности, защита информации	Начальник отдела IT	Студент Саркисов С.А.
Информационные базы и информационные потоки	Начальники отделов, сотрудники	Студент Саркисов С.А.
Информационные системы	Начальники отделов, сотрудники	Студент Саркисов С.А.
Проблемные ситуации и способы их решения	Начальники отделов, сотрудники	Студент Саркисов С.А.

1.1.3 План-график выполнения работ обследования

Для организации труда составлен план-график выполнения работ, приведенный в таблице 1.2.

Таблица 1.2 - План-график выполнения работ обследования

Наименование работы	Код работы	Исполнитель	Дата начала	Дни	Дата окончания
Обследование общей характеристики предприятия	001	Студент Саркисов С.А.	06.12.10	2	07.12.10
Обследование организационной структуры предприятия	002	Студент Саркисов С.А.	08.12.10	2	09.12.10
Обследование организационно-управленческой модели предприятия	003	Студент Саркисов С.А.	10.12.10	1	10.12.10
Выявление задач, решаемых средствами ЭИВТ	004	Студент Саркисов С.А.	13.12.10	3	15.12.10
Обследование технических средств предприятия	005	Студент Саркисов С.А.	16.12.10	2	17.12.10
Обследование программных средств предприятия	006	Студент Саркисов С.А.	20.12.10	5	24.12.10
Обследование локальной сети предприятия	007	Студент Саркисов С.А.	27.12.10	5	31.12.10
Обследование информационных баз и информационных потоков предприятия	008	Студент Саркисов С.А.	11.01.11	9	21.01.11
Обследование информационных систем предприятия	009	Студент Саркисов С.А.	24.01.11	20	18.02.11
Выявление проблемных ситуации и определение способов их решения	010	Студент Саркисов С.А.	21.02.11	13	11.03.11
Всего затрачено дней	62

1.2 Характеристика предприятия ЗАО "КИЭП "Энергомера"

1.2.1 Общая характеристика предприятия

Открытое акционерное общество Концерн "Энергомера" образовано 25 января 1994 г. на юге России и располагается по адресу г. Ставрополь ул. Ленина 415-А. В первые месяцы работы, его численность составляла 24 человека. Сегодня на его предприятиях работает более 6000 сотрудников. Сегодня концерн входит в число ведущих компаний РФ по производству средств и систем учета электроэнергии. За время деятельности компанией достигнуты значительные результаты: продукция торговой марки "Энергомера" получила широкое признание не только на территории России, но и за рубежом.

Номенклатурный ряд электротехнической продукции Концерна включает:

- электронные приборы и системы учета электроэнергии, а также соответствующее сервисное и метрологическое оборудование;

- устройства защитного отключения и учетно-распределительные электрощиты;

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

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

Основные задачи, которые ставятся перед предприятием - это:

- разработка современных, качественных приборов учета электроэнергии;

- модернизация уже существующих продуктов в соответствии с последними достижениями науки и техники;

- реализация пожеланий и устранение замечаний потребителей;

- сокращение времени затрачиваемого на разработку новых продуктов;

- возможность разработки продуктов по индивидуальным заказам.

1.2.2 Организационная структура предприятия

Организационная структура предприятия в целом представлена в виде схемы (рисунок 1.1).

Рисунок 1.1 - Организационная структура ЗАО "КИЭП "Энергомера"

Условные обозначения, применяемые на схеме и в дальнейшем:

- Гл. инженер - главный инженер предприятия;

- ГКСУ - главный конструктор систем учета;

- ГКС - главный конструктор счетчиков;

- ГКУ - главный конструктор по упаковке;

- ГКМ - главный конструктор по метрологии;

- КБСУ - конструкторское бюро систем учета;

- КБТМО - конструкторское бюро телекоммуникационного оборудования;

- ОКПП - отдел конструктивов печатных плат;

- ОКПО - отдел качества программного обеспечения;

- КБС - конструкторское бюро счетчиков;

- КБЭХЗ - конструкторское бюро электрохимической защиты;

- БПС - бюро патентования и сертификации;

- ОТП - отдел технической поддержки;

- ЛР - лаборатория;

- ОР - отдел развития;

- - административно-техническое руководство;

- - техническое руководство.

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

Организационная структура КБСУ представлена на рисунке 1.2 в виде схемы.

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

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

Рисунок 1.2 - Организационная структура КБСУ

Условные обозначения, примененные на схеме:

- ПО ЦОИ - программное обеспечение централизованной обработки информации;

- КТС - комплекс технических средств.

Организационная структура КБС представлена на рисунке 1.3 в виде схемы.



Рисунок 1.3 - Организационная структура КБС

Организационная структура ОКПО представлена на рисунке 1.4 в виде схемы.

Рисунок 1.4 - Организационная структура ОКПО

1.2.3 Организационно-управленческая модель

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

Группы функциональных задач представлены в таблице 1.3.

Таблица 1.3 - Группы функциональных задач и подзадач

Номер и название функциональной задачи	Номер и содержание функциональной подзадачи
1. Управление планированием	1.1 Разработка новых проектов
	1.2 Составление смет на поставку комплектующих
	1.3 Внесение изменений в текущие и перспективные планы производства
2. Управление производством	2.1 Получение заказов от клиентов и оформление договоров на их выполнение
	2.2 Оформление проектов и подготовка их к внедрению
	2.3 Выполнение заказов клиентов
3. Информационное обеспечение	3.1 Обеспечение руководства оперативной информацией
	3.2 Обеспечение информацией персонал
4. Автоматизация производства	4.1 Разработка автоматизированной системы управления технологическими процессами
	4.2 Использование локальных сетей в управлении
5. Обеспечение импорта	5.1 Поиск поставщиков комплектующих
	5.2 Заключение договоров
6. Обеспечение качества продукции	6.1 Тестирование программного обеспечения
	6.2 Оценка надежности продукции
	6.3 Контроль качества продукции
7. Обеспечение безопасности продукции	7.1Обеспечение безопасности продукции
	7.2 Контроль обеспечения безопасности
8. Патентование и сертификация продукции	8.1 Патентование продукции
	8.2 Сертификация продукции
9. Обеспечение поддержки клиентов	9.1 Предоставление техпомощи клиентам
	9.2 Документирование продукции
10. Разработка продукции	10.1 Разработка продукции

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

- ? - основной участник процесса;

- / - частичное участие в процессе;

- \ - основная ответственность за выполнение процесса.

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

Таблица 1.4 - Организационно-управленческая модель предприятия

1.3 Технические и программные средства ЭИВТ предприятия

1.3.1 Задачи, решаемые с использованием средств ЭИВТ

Функциональные задачи, решаемые, с использованием средств ЭИВТ представлены в таблице 1.5.

Таблица 1.5 - Функциональные задачи решаемые, с использованием средств ЭИВТ

Номер и название функциональной задачи	Номер и содержание функциональной подзадачи	Наименование подсистемы
1. Информирование	1.1 Обеспечение руководства оперативной информацией	АС "Портал"
	1.2 Обеспечение информацией персонал	АС "Портал"
2. Автоматизация	2.1 Автоматизация офиса	MS Office
	2.2 Разработка автоматизированной системы управления технологическими процессами	MS Visual Studio, NetBeans IDE
3. Обеспечение качества	3.1 Тестирование программного обеспечения	MantisBT
	3.2 Оценка надежности продукции	MantisBT
	3.3 Контроль качества продукции	MantisBT
4. Обеспечение поддержки клиентов	4.1 Предоставление техпомощи клиентам	АС "Портал самообслуживания"
	4.2 Документирование продукции	MS Office
5. Разработка продукции	5.1 Разработка ПО	MS Visual Studio, NetBeans IDE, AVR Studio
	5.2 Разработка схем	P-CAD
	5.3 Контроль версий	SVN

1.3.2 Технические средства

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

Таблица 1.6 - Основные технические средства

Группа средств	Средства	Кол-во
Компьютеры	Главный сервер	1
	Сервер печати	1
	Сервер почты	1
	Прокси-сервер	1
	Рабочие станции администрации	10
	Рабочие станции КБСУ	16
	Рабочие станции КБС	7
	Рабочие станции ОКПП	15
	Рабочие станции ОКПО	6
	Рабочие станции КБТМО	10
	Рабочие станции КБЭХЗ	6
	Рабочие станции БПС	6
	Рабочие станции ОТП	7
	Рабочие станции ЛР	7
	Рабочие станции ОР	8
Телекоммуникационное оборудование	Сетевые хабы (32 порта)	2
	Cетевые хабы (16 портов)	3
	Оборудование кабельных систем	-
Оборудование печати	Лазерный принтер	14
	Плоттер	1
Другое оборудование	Сканер	8

1.3.3 Программные средства

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

MS VS 2005 (Microsoft Visual Studio) - продукт компании Майкрософт, включающий интегрированную среду разработки программного обеспечения и ряд других инструментальных средств.

AVR Studio - интегрированная среда разработки (IDE) для разработки 8-битных AVR приложений от компании Atmel.

NetBeans IDE - свободная интегрированная среда разработки приложений на языках программирования Java, JavaFX, Python, PHP, JavaScript, C++, Ада и ряде других.

Subversion (также известная как "SVN") - свободная централизованная система управления версиями, официально выпущенная в 2004 году компанией CollabNet Inc (хранит исходные коды программы, следит за их изменениями, одно из основных достоинств - централизованное хранение данных).

P-CAD - система автоматизированного проектирования электроники (EDA) производства компании Altium. Предназначена для проектирования многослойных печатных плат вычислительных и радиоэлектронных устройств.

MantisBT - свободно распространяемая система отслеживания ошибок в программных продуктах.

"Портал" - web-приложение, предназначенное для информирования персонала предприятия (предоставляет разграниченный, по привилегиям, доступ к базе данных, в которой хранятся все электронные документы, такие как технические требования, технические задания, акты внедрения, акты соответствия и др.).

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

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

- ? - основное использование в процессе, решение основных задач;

- \ - частичное использование, вспомогательное использование,

- / - обеспечение работы других средств.

Таблица 1.7 - Использование программных средств

Программные средства

Категория

Номера задач

1

2

3

4

5

1.1

1.2

2.1

2.2

3.1

3.2

3.3

4.1

4.2

5.1

5.2

5.3

ОС Linux

Системное

/

/

/

ОС Windows ХР

Системное

/

/

/

/

/

/

/

/

/

/

/

/

MS VS 2005

Разработка ПО

?

\

\

\

?

AVR Studio

Разработка ПО

?

Netbeans IDE

Разработка ПО

?

\

\

?

SVN

Разработка ПО

\

\

\

?

MantisBT

Разработка ПО

\

?

?

\

\

\

\

\

P-CAD

Разработка схем

?

Apache

Системное

\

\

\

\

/

/

IIS

Системное

/

/

/

/

"Портал"

Общее

?

?

\

?

\

MS OFFICE

Общее

\

\

?

\

?

1.3.4 Локальная сеть предприятия

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

Основные характеристики локальной сети:

на канальном уровне используется технология Ethernet;

используются коммутаторы фирмы D-Link;

основной кабельной системой является витая пара (как экранированная, так и неэкранированная).

Схема локальной сети предприятия представлена не рисунках 1.5 и 1.6 (на рисунке 1.5 представлена часть сети, которая расположена на первом этаже здания, а на рисунке 1.6 - на втором этаже).

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

Локальная сеть построена по топологии "дерево".

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

Условные обозначения, используемые на схеме:

группа серверов - ГС;

рабочее место сотрудника с ПК, подключенным к сети - ;

сетевой хаб (32 порта) - ;

сетевой хаб (16 портов) - ;

сетевой принтер - ;

кабельная система - ;

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

Рисунок 1.5 - Схема локальной сети предприятия (первый этаж)

Рисунок 1.6 - Схема локальной сети предприятия (второй этаж)

1.3.5 Организация доступа к мировым информационным сетям

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

1.3.6 Обеспечение информационной безопасности, защита информации

На предприятии используется доменная политика безопасности, для каждого сотрудника создается учетная запись. Учётная запись - запись, содержащая сведения, которые пользователь сообщает о себе некоторой компьютерной системе. Перед каждой загрузкой операционной системы на своем компьютере, пользователь должен пройти процедуру авторизации. Учетные записи не "привязаны" к конкретным машинам пользователей (т.е. пользователи могут поменяться ЭВМ, но работать, используя свои учетными записями), а управление учетными записями производится централизовано.

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

1.3.7 Информационные базы и информационные потоки

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

Рисунок 1.7 - Схема утверждения технического задания

1.3.8 Проблемные ситуации и способы их решения

Основные проблемные ситуации (и способы их решения), имеющиеся на предприятии представлены в таблице 1.8.

Таблица 1.8 - Проблемные ситуации и способы их решения

Проблемная ситуация	Способ решения
Недостаточная автоматизация	Разработка и внедрение ИС
Устаревшее оборудование	Замена оборудования
Нехватка квалифицированных кадров	Набор и обучение кадров
Нехватка специализированного ПО	Приобретение необходимого ПО
Нехватка рабочего пространства	Приобретение зданий под офисы

1.3.9 Выбор проблемной ситуации для решения

Одной из центральных проблем является недостаточная автоматизация производственных процессов, например, в отделе качества программного обеспечения проблемой является - автоматизация процесса тестирования PLC-модемов и процессов сбора, обработки и хранения информации о проведенных тестах, предоставления этой информации пользователям (работникам предприятия). На предприятии успешно функционирует система MantisBT - свободно распространяемая система отслеживания ошибок в программных продуктах, но этого не достаточно, требуется более конкретизированная система. Таким образом, разработка информационной подсистемы тестирования PLC-модемов является актуальной и важной.

Операторами и пользователями информационной подсистемы являются работники предприятия, чья деятельность связана с PLC-модемами.

Требования к проекту формулируемые со стороны заказчика:

1) информационная подсистема тестирования PLC-модемов для отдела качества ЗАО "КИЭП "Энергомера" предназначена для автоматизации процессов тестирования PLC-модемов и процессов сбора, обработки и хранения информации о проведенных тестах, а также предоставления этой информации пользователям;

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

3) в системе должны быть поддержаны два типа тестирований:

тестирование AT-команд;

тестирование команд протокола NNCL.

4) для всех тестов должна указываться следующая информация:

время начала проведения тестирования;

время завершения проведения тестирования;

режим тестирования;

пользователь, проводивший тестирование.

5) для тестирований команд протокола NNCL должна предоставляться следующая информация:

количество ошибок обнаруженных при тестировании;

количество запросов, на которые не получены ответы;

входные данные к тестированию (адреса модемов).

6) должен контролироваться доступ к системе.

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

1.4 Формулировка задач проектирования

1.4.1 Общие сведения о проекте

Проект называется "Информационная подсистема PLC-Tester". Разработчиком является отдел качества программного обеспечения ЗАО "КИЭП "Энергомера". Исполнителем проекта является студент группы ИС-061 Саркисов Сергей Артурович, техник отдела качества программного обеспечения ЗАО "КИЭП "Энергомера".

1.4.2 Назначение, цели создания информационной подсистемы

Основные цели создания информационной подсистемы:

повышения качества тестирования встроенного программного обеспечения PLC-модемов;

повышение производительности труда;

снижение нагрузки на персонал;

повышение прибыли.

1.4.3 Характеристика объекта автоматизации

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

обмен данными между ПК и PLC-модемом;

обработка полученных данных.

В силу особенностей модемов, в системе выделены два типа тестов:

тестирование AT-команд;

тестирование команд протокола NNCL.

Тестирование проводится в двух основных режимах:

режим тестирования функциональности;

нагрузочный режим.

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

MAC-адреса модемов, задействованных в тестировании;

режим теста (нагрузочный тест, функциональное тестирование);

тип адресации (указывает используемый тип адресации);

дополнительные данные (последовательный порт и его настройки).

Входными данными для процесса тестирования AT-команд являются:

режим теста (нагрузочный тест, функциональное тестирование);

дополнительные данные (последовательный порт и его настройки).

Выходными данными для тестов являются:

результат завершения теста;

количество ошибок (только тесты команд протокола NNCL);

количество неполученных ответов (тесты команд NNCL);

журналы тестов.

Управляющими воздействиями являются:

запуск теста;

остановка теста;

сохранение результатов тестирований в базу данных.

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

1.4.4 Требования к подсистеме

Требования к проектируемой информационной подсистеме удобно проиллюстрировать диаграммой вариантов ее использования в нотации UML (рисунок 1.8). На диаграмме представлены шесть актеров (представляют основные модули подсистемы и её пользователей), и самые основные функции, которые они должны выполнять. Система должна быть разработана по технологии "клиент/сервер" и состоять из трех основных модулей:

модуль автоматизации процесса тестирования (и сбора данных);

база данных (для долгосрочного хранения данных, полученных в результате тестирований);

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

база данный тестирование программный

Рисунок 1.8 - Диаграмма вариантов использования системы в нотации UML

В системе три основных типа пользователей:

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

целевые пользователи (имеют доступ только к модулю для обработки данных и предоставления информации);

администраторы системы (имеют доступ к базе данных, без каких-либо ограничений).

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

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

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

Информационная подсистема тестирования PLC-модемов должна функционировать на персональных компьютерах под управлением операционных систем общего назначения. Модуль автоматизации процесса тестирования должен быть разработан для платформы Microsoft Windows.

Информационная подсистема тестирования PLC-модемов не должна зависеть от других ИС.

1.4.5 Состав и содержание работ по созданию подсистемы

Состав и содержание работ по созданию системы должны удовлетворять требованиям ГОСТ 34.601-90.

ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы (дальше АС):

1. Формирование требований к АС:

обследование объекта и обоснование необходимости создания АС;

формирование требований пользователя к АС;

оформление отчета о выполнении работ и заявки на разработку АС.

2. Разработка концепции АС:

изучение объекта;

проведение необходимых научно-исследовательских работ;

разработка вариантов концепции АС и выбор варианта концепции,

АС, удовлетворяющего требованиям пользователей;

оформление отчета о проделанной работе.

3. Техническое задание:

разработка и утверждение технического задания на создание АС.

4. Эскизный проект:

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

разработка документации на АС и ее части.

5. Технический проект:

разработка проектных решений по системе и ее частям;

разработка документации на АС и ее части;

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

разработка заданий на проектирование в смежных частях проекта.

6. Рабочая документация:

разработка рабочей документации на АС и ее части;

разработка и адаптация программ.

7. Ввод в действие:

подготовка объекта автоматизации;

подготовка персонала;

комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями).

строительно-монтажные работы;

пусконаладочные работы;

проведение предварительных испытаний;

проведение опытной эксплуатации;

проведение приемочных испытаний;

8. Сопровождение АС:

выполнение работ в соответствии с гарантийными обязательствами;

послегарантийное обслуживание.

Сроки выполнения и исполнители представлены в таблице 1.9.

Таблица 1.9 - Сроки выполнения работ и исполнители

Стадии	Исполнители	Сроки
1	Начальник ОКПО	20.03.2011
2	Студент Саркисов С.А.	30.03.2011
3	Начальник ОКПО	05.04.2011
4	Студент Саркисов С.А.	12.04.2011
5	Студент Саркисов С.А.	20.04.2011
6	Студент Саркисов С.А.	10.05.2011
7	Студент Саркисов С.А.	12.05.2011
8	Студент Саркисов С.А.	-

1.4.6 Порядок контроля приемки подсистемы

Испытания проводятся специальной группой, в состав которой входят:

начальник отдела качества программного обеспечения;

главный конструктор систем учета;

исполнитель;

группа инженеров отдела качества программного обеспечения.

Результаты испытаний фиксируются в протоколе испытаний. Испытания проводятся на объекте, на котором будет функционировать система. Приёмка системы в целом осуществляется комиссией и утверждается у директора предприятия. В итоге оформляется актом сдачи-приёмки работ.

1.4.7 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу подсистемы в действие

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

предоставлена ЭВМ в качестве сервера (с сетевой картой);

предоставлена возможность подключения ЭВМ к сети предприятия;

на ЭВМ установлена операционная система семейства Unix или Windows;

разработчику предоставлен доступ к ЭВМ.

1.4.8 Требования к документированию

На систему должна быть составлена документацию, которая должна соответствовать требованиям государственных стандартов. Должны быть созданы следующие документы:

руководство администратора системы;

руководство оператора системы;

руководство пользователя.

1.4.9 Источники разработки

Источниками разработки являются:

ГОСТ 34.602.89 Комплекс стандартов на автоматизированные системы.

заказ на разработку;

техническое задание;

отчёт о преддипломной практике.

Выводы

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

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

модель управления предприятием;

информационные системы, функционирующие на предприятии;

локальная сеть предприятия и прочие программно-технические средства.

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

2. РАЗРАБОТКА ИНФОРМАЦИОННОЙ ПОДСИСТЕМЫ PLC-TESTER

2.1 Обоснование выбора программного обеспечения

Информационная подсистема тестирования встроенного программного обеспечения PLC-модемов (диаграмма размещения в приложении Б) состоит из трех основных модулей:

- базы данных;

- модуля тестирования и сбора данных (результатов тестирований);

web-приложения (для передачи обработанной информации из базы данных пользователю).

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

В качестве СУБД выбрана MySQL, это свободная, кроссплатформенная система управления базами данных, MySQL является собственностью компании Oracle Corporation, распространяется под GNU General Public License или под собственной коммерческой лицензией.

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

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

MySQL является решением для малых и средних приложений.

Для разработки и администрирования базы данных выбраны следующие программные продукты:

dbForge Studio for MySQL (имеет и коммерческую и свободную лицензии), для ОС Windows;

MySQL Administrator - кроссплатформенное средство для администрирования СУБД MySQL;

phpMyAdmin - web-приложение с открытым кодом, написанное на языке PHP и представляющее собой web-интерфейс для администрирования СУБД MySQL, позволяет через браузер осуществлять администрирование сервера MySQL, запускать команды SQL и просматривать содержимое таблиц и баз данных. Приложение пользуется большой популярностью у web-разработчиков, так как позволяет управлять СУБД MySQL без непосредственного ввода SQL команд, предоставляя дружественный интерфейс.

Модуль тестирования и сбора данных является составным:

PLCTester.exe (разрабатывается на платформе .NET, язык C#);

TAT.dll (разрабатывается на языке C/C++);

TNNCL.dll (разрабатывается на языке C/C++).

Для реализации модуля PLCTester.exe выбрана интегрированная среда разработки SharpDewelop - свободная среда разработки для C#, Visual Basic .NET, Boo, IronPython, IronRuby, F#, C++.

Для разработки модулей TAT.dll и TNNCL.dll и web-приложения выбрана NetBeans IDE - свободная интегрированная среда разработки приложений на языках программирования Java, JavaFX, Python, PHP, JavaScript, C++, Ада и ряде других.

Для разработки программ в среде NetBeans IDE и для успешной инсталляции и работы самой среды NetBeans IDE должен быть предварительно установлен Sun JDK или J2EE SDK подходящей версии. Среда разработки NetBeans по умолчанию поддерживала разработку для платформ J2SE и J2EE. Начиная с версии 6.0 Netbeans поддерживает разработку для мобильных платформ J2ME, C++ (только g++), PHP и Ruby без установки дополнительных компонентов.

Проект NetBeans IDE поддерживается и спонсируется компанией Oracle.

Однако разработка NetBeans ведется независимо сообществом разработчиков-энтузиастов (NetBeans Community) и компанией NetBeans Org.

Для реализации и исполнения web-приложения выбраны язык программирования php и HTTP-сервер Apache.

Apache является свободным, кроссплатформенным ПО, поддерживает операционные системы Linux, BSD, Mac OS, Microsoft Windows, Novell NetWare, BeOS.

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

В целом, выбор сделан в пользу свободного и кросплатформенного (где это необходимо) программного обеспечения. Целевой операционной системой для модуля тестирования и сбора данных выбрана Microsoft Windows, а СУБД и web-приложение могут работать и на других операционных системах (планируется дистрибутив Linux Debian 6.0, который считается одним из самых надежных дистрибутивов Linux, используемых в качестве операционных систем на серверных машинах).

2.2 Проектирование и разработка БД

2.2.1 Определение сущностей

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

В системе, производятся тесты двух, принципиально разных типов:

тестирование команд протокола NNCL;

тестирование AT-команд.

NNCL - Nero Network Control Level, протокол обмена ПК (или УСПД - устройством сбора и передачи данных) с PLC-модемом по последовательному порту. Этот протокол используется в управлении сетью из PLC-модемов, построенной на протоколе NNL (Nero Network Level).

Каждый тип теста будет представлен отдельной сущностью:

NNCLTest;

ATTest.

Каждый тест, независимо от типа, должен проводиться, как минимум в двух режимах:

режим функционального тестирования;

режим нагрузочного тестирования.

Сущность, описывающая режим тестирования - TestMode.

Результат теста представлен сущностью EndCode.

К каждому тесту может прилагаться дополнительная информация, например, в виде журналов, сущности: NNCLLog и ATLog.

Для разделения журналов на типы представлена сущность LogType.

Для тестирования команд протокола NNCL используются дополнительные входные данные, которые представлены сущностью NNCLInputData.

Каждое тестирование проводится от имени пользователя, которого представляет сущность User, так же пользователи имеют разные права доступа к системе, поэтому выделена сущность UserType, которая представляет тип пользователя (администратор, просто пользователь и другие).

2.2.2 Определение зависимостей между сущностями

Зависимости между сущностями обычно представляют в виде ER-диагаммы (рисунок 2.1). ER-диаграмма представлена в нотации "Crow's Foot". Данная нотация была предложена Гордоном Эверестом (англ. Gordon Everest) под названием Inverted Arrow ("Перевёрнутая стрелка"), однако сейчас чаще называемая Crow's Foot ("Воронья лапа") или Fork ("Вилка").

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

Рисунок 2.1 - ER-диаграмма базы данных в нотации "Crow's Foot"

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

2.2.3 Определение атрибутов сущностей, создание первичных и внешних ключей

Сущность NNCLTest имеет следующие атрибуты:

nncl_test_id - первичный ключ;

begin - дата и время начала тестирования;

end - дата и время завершения тестирования;

input_data - входные данные для теста (внешний ключ);

nncl_test_mode - режим теста (внешний ключ);

command_count - количество отправленных команд;

error_count - количество ошибок;

no_answer_count - количество запросов, оставшихся без ответа;

end_code - код завершения (внешний ключ);

user_login - логин пользователя (внешний ключ).

Сущность ATTest имеет следующие атрибуты:

at_test_id - первичный ключ;

begin - дата и время начала тестирования;

end - дата и время завершения тестирования;

at_test_mode - режим теста (внешний ключ);

end_code - код завершения (внешний ключ);

user_login - логин пользователя (внешний ключ).

Сущность TestMode имеет следующие атрибуты:

test_mode_id - первичный ключ;

test_mode_name - наименование типа тестирования;

description - описание;

nncl_only - принадлежность режима теста к типу теста.

Сущность EndCode имеет следующие атрибуты:

end_code_id - первичный ключ;

end_code_name - наименование кода завершение;

description - описание.

Сущность NNCLLog имеет следующие атрибуты:

nncl_log_id - первичный ключ;

nncl_test - тест, к которому относится лог (внешний ключ);

nncl_log_file - прикрепляемый файл;

nncl_log_type - тип прикрепляемого файла (внешний ключ);

description - описание.

Сущность ATLog имеет следующие атрибуты:

at_log_id - первичный ключ;

at_test - тест, к которому относится лог (внешний ключ);

at_log_file - прикрепляемый файл;

at_log_type - тип прикрепляемого файла (внешний ключ);

description - описание.

Сущность LogType имеет следующие атрибуты:

log_type_id - первичный ключ;

log_type_name - наименование;

description - описание.

Сущность NNCLInputData имеет следующие атрибуты:

nncl_input_id - первичный ключ;

first_mac - MAC-адрес первого модема в списке тестировании;

last_mac - MAC-адрес последнего модема в списке тестировании;

host_mac - MAC-адрес host-модема, участвующего в тестировании;

Сущность User имеет следующие атрибуты:

login - логин пользователя (первичный ключ);

password - пароль пользователя;

email - адрес электронной почты пользователя;

user_type - тип пользователя (внешний ключ);

first_name - имя пользователя;

second_name - фамилия пользователя;

third_name - отчество пользователя.

Сущность UserType имеет следующие атрибуты:

user_type_id - первичный ключ;

user_type_name - имя типа пользователя;

description - описание;

can_add - возможность добавлять информацию;

can_delete - возможность удалять информацию.

Функциональные зависимости представлены на рисунках 2.2 - 2.10.

Рисунок 2.2 - Функциональные зависимости между атрибутами сущности NNCLTest

Рисунок 2.3 - Функциональные зависимости между атрибутами сущности TestMode

Рисунок 2.4 - Функциональные зависимости между атрибутами сущности ATTest



Рисунок 2.5 - Функциональные зависимости между атрибутами сущности EndCode

Рисунок 2.6 - Функциональные зависимости между атрибутами сущности NNCLLog

Рисунок 2.7 - Функциональные зависимости между атрибутами сущности LogType

Рисунок 2.8 - Функциональные зависимости между атрибутами сущности ATLog



Рисунок 2.9 - Функциональные зависимости между атрибутами сущности NNCLInputData

Рисунок 2.10 - Функциональные зависимости между атрибутами сущностей UserType и User

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

2.2.4 Создание физической модели данных

В таблицах 2.1 - 2.9 представлены составы таблиц базы данных. Для каждого поля таблицы указан тип данных (столбец "Тип поля"). Для некоторых полей введен запрет на использование неопределенных значений (столбец "NULL"). Примечание - Если в столбце "NULL" указано значение "Нет", это означает, что данное поле, при заполнении таблицы в базе данных, не может иметь неопределенные значения, в противном случае поле может иметь неопределенные значения.

Таблица 2.1 - Состав таблицы NNCLTest

Наименование атрибута	Тип поля	NULL
nncl_test_id nncl_test_mode begin end command_count error_count no_answer_count user_login end_code input_data	INT(11) INT(11) DATETIME DATETIME INT(11) INT(11) INT(11) VARCHAR(30) INT(11) INT(11)	Нет Нет Нет Нет Нет Нет Нет Нет Нет Нет

Ключи таблицы:

nncl_test_id (первичный ключ), по полю nncl_test_id;

FK_nncltest_endcode_end_code_id, по полю end_code;

FK_nncltest_user_login, по полю user_login;

FK_nncltest_nnclinputdata_nncl_input_id, по полю input_data;

FK_nncltest_testmode_test_mode_id, по полю nncl_test_mode.

Таблица 2.2 - Состав таблицы ATTest

Наименование атрибута	Тип поля	NULL
at_test_id at_test_mode begin end end_code user_login	INT(11) INT(11) DATETIME DATETIME INT(11) VARCHAR(30)	Нет Нет Нет Нет Нет Нет

Ключи таблицы:

at_test_id (первичный ключ), по полю at_test_id;

FK_attest_endcode_end_code_id, по полю end_code;

FK_attest_user_login, по полю user_login;

FK_attest_testmode_test_mode_id, по полю at_test_mode.

Таблица 2.3 - Состав таблицы TestMode

Наименование атрибута	Тип поля	NULL
test_mode_id test_mode_name description nncl_only	INT(11) INT(11) VARCHAR(255) BOOL	Нет Нет Да Нет

Ключи таблицы:

test_mode_id (первичный ключ), по полю test_mode_id.

Таблица 2.4 - Состав таблицы EndCode

Наименование атрибута	Тип поля	NULL
end_code_id end_code_name description	INT(11) VARCHAR(50) VARCHAR(255)	Нет Нет Да

Ключи таблицы:

end_code_id (первичный ключ), по полю end_code_id.

Таблица 2.5 - Состав таблицы NNCLLog

Наименование атрибута	Тип поля	NULL
nncl_log_id nncl_test nncl_log_file nncl_log_type description	INT(11) INT(11) VARCHAR(255) INT(11) VARCHAR(255)	Нет Нет Нет Нет Да

Ключи таблицы:

end_code_id (первичный ключ), по полю end_code_id;

FK_nncllog_logtype_log_type_id, по полю nncl_log_type;

FK_nncllog_nncltest_nncl_test_id, по полю nncl_test.

Таблица 2.6 - Состав таблицы LogType

Наименование атрибута	Тип поля	NULL
log_type_id log_type_name description	INT(11) VARCHAR(50) VARCHAR(255)	Нет Нет Да

Ключи таблицы:

log_type_id (первичный ключ), по полю log_type_id.

Таблица 2.7 - Состав таблицы ATLog

Наименование атрибута	Тип поля	NULL
at_log_id at_test at_log_type at_log_file description	INT(11) INT(11) INT(11) VARCHAR(255) VARCHAR(255)	Нет Нет Нет Нет Да

Ключи таблицы:

at_log_id (первичный ключ), по полю at_log_id;

FK_atlog_attest_at_test_id, по полю at_test;

FK_atlog_logtype_log_type_id, по полю at_log_type.

Таблица 2.8 - состав таблицы NNCLInputData

Наименование атрибута	Тип поля	NULL
nncl_input_id first_mac last_mac host_mac	INT(11) INT(11) INT(11) INT(11)	Нет Нет Нет Нет

Ключи таблицы:

nncl_input_id (первичный ключ), по полю nncl_input_id.

В таблицах 2.9 и 2.10 представлены описания таблиц User и UserType, представляющие одноименные сущности.

Таблица 2.9 - состав таблицы User

Наименование атрибута	Тип полей	NULL
login password email user_type first_name second_name third_name	VARCHAR(30) VARCHAR(50) VARCHAR(100) INT(11) VARCHAR(255) VARCHAR(255) VARCHAR(255)	Нет Нет Нет Нет Нет Нет Нет

Ключи таблицы:

login (первичный ключ), по полю login;

FK_user_usertype_user_type_id, по полю user_type.

Таблица 2.10 - состав таблицы UserType

Наименование атрибутов	Тип поля	NULL
user_type_id user_type_name description can_add can_delete	INT(11) VARCHAR(30) VARCHAR(255) BOOL BOOL	Нет Нет Да Нет Нет

Единственный ключ таблицы - login (первичный ключ), по полю login.

2.2.5 Разработка хранимых процедур

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