на тему: «АВТОМАТИЗИРОВАННАЯ СИСТЕМА ФОРМИРОВАНИЯ ОТЧЁТОВ ОПЕРАТОРОВ УЛЬТРАЗВУКОВЫХ УСТАНОВОК «NUKEM» и «NORDINKRAFT»

0

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

на тему:

«АВТОМАТИЗИРОВАННАЯ СИСТЕМА ФОРМИРОВАНИЯ ОТЧЁТОВ ОПЕРАТОРОВ УЛЬТРАЗВУКОВЫХ УСТАНОВОК «NUKEM» и «NORDINKRAFT»»

Аннотация

В дипломной работе разработана автоматизированная информационная система для автоматизации процесса формирования отчётов операторов ультразвуковых установок «Nukem» и «NordinKraft».

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

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

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

Пояснительная записка содержит 106 страниц, в том числе 17 таблиц, 31 рисунков, 27 использованных источников и 3 приложения.

Annotation

In research paper developed an automated information system to automate the reporting operators ultrasonic devices «Nukem» and «NordinKraft».

In the first chapter of the explanatory note analyzed the domain considered and defining the information flows that need to be automated. The analysis of the existing analogue and identified their weaknesses. Justified the development of its own software system. The choice of the mathematical apparatus. On this basis the statement of the problem is formed.

The second chapter is justified choice of tools, development of database design. Proposed software architecture of the complex. The analysis of the input data and the determination of the output data. Algorithms of solving the problem. Testing of the developed software.

In the third chapter of a manual system programmer, and operator's manual.

Explanatory note contains 106 pages, including 17 tables, 31 figures, 27 the resources and 3 applications.

Содержание

Введение.................................................................................................................. 6

1 Системный анализ информационных процессов формирования отчётов

операторов ультразвуковых установок................................................................. 8

1.1 Формирование функциональной и потоковой моделей информационных процессов................................................................................................................. 8

1.2 Анализ аналогов средств формирования отчётов......................................... 15

1.3 Выбор метода классификации продукции прокатных станов по дефектам. 18

1.4 Постановка задачи дипломной работы......................................................... 20

Выводы по разделу............................................................................................... 23

2 Реализация программного проекта.................................................................. 24

2.1 Формирование функциональной схемы программных средств................... 24

2.2 Выбор и обоснование инструментальных средств разработки.................... 27

2.3 Проектирование базы данных........................................................................ 34

2.4 Разработка укрупнённого алгоритма и алгоритма метода.......................... 48

2.5 Тестирование разработанного программного средства............................... 52

Выводы по разделу............................................................................................... 57

3 Технологический раздел.................................................................................... 58

3.1 Разработка руководства системного программиста..................................... 58

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

Выводы по разделу............................................................................................... 67

Заключение............................................................................................................ 68

Список использованных источников................................................................... 69

Приложение А SQL - скрипты.............................................................................. 70

Приложение Б Листинг программы..................................................................... 75

Введение

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

Открытое акционерное общество «Уральская сталь» – единственное в мире предприятие, производящее литейный хромоникелевый сложнолегированный чугун с использованием местной природно-легированной руды. Производственные мощности предприятия рассчитаны на выпуск более 4 млн тонн стали в год. В состав предприятия входит аглококсодоменное, сталеплавильное и прокатное производство, а также вспомогательные, энергетические и ремонтные цеха. В листопрокатном цеху №1 для контроля качества выпускаемой продукции установлены автоматизированные ультразвуковые установки (УЗК) «Nukem» и «Nordinkraft» в потоке стана 2800, обеспечивающие 100 % контроль сплошности листового проката. В день проверяется большое количество листового проката, что ведёт за собой большое количество информации о нём. Во время работы с операторов УЗК требуют отчёты о проведённой проверке листопрокатной продукции. Таким образом, требуется создание автоматизированной информационной системы позволяющей обеспечивать доступ к базе данным SQL сервера, выборку данных, а также необходимо формировать отчеты по интересующей установке.

Для достижения поставленной цели необходимо решить ряд задач по дисциплине 230100.62 «ЭВТ»:

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

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

1 Системный анализ информационных процессов формирования отчётов операторов ультразвуковых установок

Формирование функциональной и потоковой моделей информационных процессов

Назначение и организационно-штатная структура предприятия.

ОАО «Уральская Сталь» создано 5 марта 1955 г. Полное наименование предприятия (согласно Уставу): Открытое Акционерное Общество «Уральская Сталь». Сокращенное наименование: ОАО «Уральская Сталь» [1].

Общество имеет представительство: Представительство открытого акционерного общества «Уральская Сталь» в городе Москва. Место нахождения представительства: 109028, город Москва, улица Земляной вал, дом 50А/8, строение 2.

ОАО «Уральская сталь» является металлургическим дивизионом ОАО «Металлоинвест» [1]. «Металлоинвест» – один из крупнейших и динамично развивающихся холдингов России, созданный для реализации масштабных инвестиционных проектов в металлургии, горно-добывающей промышленности и тяжелом машиностроении.

В состав Холдинга входят ведущие предприятия горнодобывающей и металлургической отраслей России:

ОАО «Михайловский ГОК»;
ОАО «Лебединский ГОК»;
ОАО «Оскольский электрометаллургический комбинат»;
ОАО «Уральская сталь».

Холдинг «МЕТАЛЛОИНВЕСТ»:

владеет крупнейшими в мире запасами железной руды;
осваивает крупнейшее из разведанных в мире железорудное месторождение Курской магнитной аномалии;
крупнейший производитель железорудной продукции в СНГ;
четвертый производитель ЖРС в мире;
единственный производитель ГБЖ в Европе;
реализует более 10% от суммарного объема мировой торговли металлизированным сырьем.

Холдинг «МЕТАЛЛОИНВЕСТ» входит в пятерку крупнейших российских металлургических компаний, занимая ведущие позиции в важнейших нишах стальной продукции в России:

мостосталь – 66%;
продукция для метизных предприятий – 50%;
трубная заготовка – 40%;
штрипс для ТБД – 23%;
толстолистовой прокат – 19%.

Перспективное развитие холдинга «МЕТАЛЛОИНВЕСТ» предполагает завоевание лидерских позиций на российском и зарубежном горно-металлургическом рынках за счет реализации единой стратегии развития предприятий, увеличения объемов продукции с высокой добавленной стоимостью, внедрения новых технологий и совершенствования производственной базы.

Управляющая компания «МЕТАЛЛОИНВЕСТ» была образована с целью эффективного управления активами, консолидированными в рамках Холдинговой компании «МЕТАЛЛОИНВЕСТ».

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

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

Краткая характеристика видов продукции ОАО «Уральская Сталь»:

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

Кроме того, продуктами ОАО «Уральская Сталь» являются кокс и химические продукты коксования, чугун литейный и передельный, товары народного потребления.

ОАО «Уральская Сталь» поставляет на экспорт такие виды продукции, как прокат (толстолистовой и сортовой), чугун, продукцию коксохимического производства (сульфат аммония, каменноугольная смола, бензол.

В настоящее время комбинат экспортирует металлопродукцию, в основном, в Филиппины, Тайвань, Саудовскую Аравию, Таиланд, Малайзию, Сингапур, КНР, Иран, Турцию, Грецию, а также осуществляет небольшие поставки в США, Италию и Великобританию.

Основной рынок – Китай и страны Юго-Восточной Азии, а для привлечения иностранных покупателей проводятся различные мероприятия:

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

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

Особенностью ОАО «Уральская Сталь» является то, что при большом объеме производства продукции выплавляют только спокойную сталь, в том числе свыше 60% легированных и низколегированных марок, и высокопрочную сталь специального назначения. На предприятии выплавляют около 100 различных марок стали. Половина всего объема производства – сталь с массовой долей серы менее 0.025%.

ОАО «Уральская Сталь», является градообразующим предприятием для Новотроицка, поскольку на нем трудится 24,3 тыс. человек из 109,7 тыс. человек, что составляет 22% населения города Новотроицка.

Технологическая схема основного производства ОАО «Уральская Сталь» представлена на рисунке 1.1.

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

Суть данной структуры состоит в том, что при линейном руководстве специалисты образуют штаб, который готовит для него данные для компетентного решения специальных вопросов. В этом случае функциональные органы находятся в подчинении линейного руководителя. Их распоряжения отдаются производственным подразделениям только после согласования с ним, что способствует более компетентному решению вопросов. Организационная структура ОАО «Уральская Сталь» (ОХМК) имеет линейно-функциональную структуру управления. При линейно-функциональной структуре управления резко увеличивается нагрузка на линейного руководителя, который должен исполнять роль посредника между функциональными службами и подчиненными ему производственными подразделениями. Он воспринимает потоки информации от подчиненных подразделений, дает задания функциональным службам, вырабатывает решения, отдает команды сверху вниз.

Рисунок 1.1 - Технологическая структура ОАО «Уральская сталь»

На промышленных предприятиях применяются четыре основные организационные структуры систем управления:

линейная;
функциональная;
линейно-функциональная;
линейно-штабная и матричная.

Суть данной структуры состоит в том, что при линейном руководстве специалисты образуют штаб, который готовит для него данные для компетентного решения специальных вопросов. В этом случае функциональные органы находятся в подчинении линейного руководителя. Их распоряжения отдаются производственным подразделениям только после согласования с ним, что способствует более компетентному решению вопросов. Организационная структура ОАО «Уральская Сталь» (ОХМК) имеет линейно-функциональную структуру управления. При линейно-функциональной структуре управления резко увеличивается нагрузка на линейного руководителя, который должен исполнять роль посредника между функциональными службами и подчиненными ему производственными подразделениями. Он воспринимает потоки информации от подчиненных подразделений, дает задания функциональным службам, вырабатывает решения, отдает команды сверху вниз.

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

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

ОАО «Уральская Сталь» относится к частной форме собственности. Предприятие (общество) является юридическим лицом и имеет в собственности обособленное имущество, отражаемое на самостоятельном балансе.

На промышленных предприятиях применяются четыре основные организационные структуры систем управления:

линейная;
функциональная;
линейно-функциональная;
линейно-штабная и матричная.

Организационная структура ОАО «Уральская Сталь» (ОХМК)

Суть данной структуры состоит в том, что при линейном руководстве специалисты образуют штаб, который готовит для него данные для компетентного решения специальных вопросов. В этом случае функциональные органы находятся в подчинении линейного руководителя. Их распоряжения отдаются производственным подразделениям только после согласования с ним, что способствует более компетентному решению вопросов. Организационная структура ОАО «Уральская Сталь» (ОХМК) имеет линейно-функциональную структуру управления. При линейно-функциональной структуре управления резко увеличивается нагрузка на линейного руководителя, который должен исполнять роль посредника между функциональными службами и подчиненными ему производственными подразделениями. Он воспринимает потоки информации от подчиненных подразделений, дает задания функциональным службам, вырабатывает решения, отдает команды сверху вниз. Основой линейно-функциональной структуры является линейное управление. Роль же функциональных органов изменяется в зависимости от уровня управления. Чем выше уровень, тем большую роль играют функциональные органы.

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

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

Цель анализа информационных потоков предприятия ОАО «Уральская сталь» — выявление точек дублирования, избытка и недостатка информации, причин ее сбоев и задержек.

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

Каждый информационный поток — единичное перемещение информации имеет следующие признаки:

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

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

На предприятии ОАО «Уральская Сталь» в Листопрокатном цеху находятся 2 ультразвуковые установки (УЗК). Информация с обоих УЗК сохраняется на SQL Сервере. Операторы УЗК, инженер УТА и другие, могут, запросит необходимую информацию у SQL сервера, и сформировать из неё отчёт.

Структура информационных потоков изображена на рисунке 1.2.

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

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

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

Функциональная схема АИС и схема потоков данных изображены на рисунках 1.3, 1.4.

Рисунок 1.2 – Структура информационных потов

Рисунок 1.3 – Функциональная схема АИС

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

Рисунок 1.4 – Схема потоков данных

Следовательно, создание автоматизированной системы формирования отчетов операторов ультрозвуковых установок «Nukem» и «Nordinkraft» и поддержки принятия решения о классификации брака на группы является актуальной работой [2,3].

1.2 Анализ аналогов средств формирования отчётов

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

Active XL Report мощный генератор отчетов для Microsoft Excel, реализованный в виде ActiveX компонента [4]. Он ориентирован на разработчиков приложений в Microsoft Access, Visual Basic, Visual FoxPro, Visual C++, Word, Excel и т. д.

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

Интерфейс программы представлен на рисунке 1.5.

Рисунок 1.5 – Интерфейс Active XL Report

SharpShooter Reports– компонент, способный решать самые сложные задачи отчетности и анализа данных при создании функциональных и эффективных бизнес приложений [5]. Отличительной особенностью SharpShooter Reports является возможность строить отчёты в дизайнере или с помощью Мастера отчётов (Wizard) и экспортировать готовый отчет в наиболее популярные форматы – XPS, PDF, HTML, EMF, BMP, JPG, GIF, TIFF, PNG, Excel, Excel (XML), CSV, TXT и RTF.

Помимо этого, SharpShooter Reports включает следующие возможности:

дизайн отчётов:
создание отчётов любой сложности (многоколоночные, параметризированные, Side-by-Side, суботчёты, отчёты с группами и т.п.);
модификация отчётов и внесение изменений конечным пользователем в готовый документ с помощью редактора отчётов;
создание шаблона отчета, содержащего все повторяющиеся элементы и использование его в качестве клише при разработке отчетов в дальнейшем, тем самым значительно сокращая время дизайна набора отчетов.
работа с источниками данных:
использование любых источников данных .NET, поддерживаемых вашим приложением;
построение отчетов с привязкой или без привязки к источнику данных.
визуализация:
построение сводных таблиц на основе любых источников данных, доступных в отчете;
создание графиков для наглядного отображения данных отчёта;
поддержка двумерных штрих кодов, картинок, фигур.
просмотр отчётов:
компонент для просмотра отчётов в Windows Forms приложениях;
компонент для просмотра отчётов в ASP.NET приложениях.

Интерфейс SharpShooter Reports представлен на рисунке 1.6.

Рисунок 1.6 – Интерфейс SharpShooter Reports

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

1.3 Выбор метода классификации продукции прокатных станов по дефектам

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

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

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

Например, если наблюдаемый объект характеризуется двумя признаками Х₁ (вид брака) и Х₂ (площадь брака), то при использовании методов кластерного анализа оба эти признака учитываются одновременно при отнесении наблюдения в ту или иную группу.

Методы кластерного анализа позволяют решать следующие задачи:

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

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

X₁,X₂,…, X_n – совокупность объектов наблюдения;
X_i = (X_i₁,X_i₂,…, X_im₎ – i-е наблюдение в m-мерном пространстве признаков (i = 1,2,…n);
d_kl – расстояние между k-м и l-м объектами;
z_ij – нормированные значения исходных переменных;
D – матрица расстояний между объектами.

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

В кластерном анализе для количественной оценки сходства вводится понятие метрики. Каждый объект описывается m-признаками и представлен как точка в m-мерном пространстве. Сходство или различие между классифицируемыми объектами устанавливается в зависимости от метрического расстояния между ними.

В кластерном анализе используются различные меры расстояния между объектами, одно из них евклидово расстояние, вычисляемое по формуле (1.1):

, (1.1)

где d_ij – расстояние между i-ым и j-ым объектами;

x_il, x_jl– значения l-переменной и соответственно у i-го и j-го объектов;

X_i, X_j– векторы значений переменных у i-го и j-го объектов;

S– общая ковариационная матрица;

ƒ_l – вес, приписываемый l-й переменной.

Если алгоритм кластеризации основан на измерении сходства между переменными, то в качестве мер сходства могут быть использованы:

линейные коэффициенты корреляции;
коэффициенты ранговой корреляции;
коэффициенты контингенции и т.д.

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

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

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

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

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

Существуют несколько способов выбора радиуса сферы. Если d_lk – расстояние между l-м и k-м объектами, то в качестве нижней границы радиуса (R_н) выбирают R_н = min{d(X_l,X_k)}, а верхняя граница радиуса R_в может быть определена как R_в = max{d(X_l,X_k)}.

Если начинать работу алгоритма с величины R_н = mind(X_l,X_k)+δ и при каждом его повторении изменять δ на небольшую величину, то можно выявить значения радиусов, которые приводят к образованию одного и того же числа кластеров, т.е. к устойчивому разбиению.

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

Судить о качестве разбиения позволяют и некоторые простейшие приемы. Например, можно сравнивать средние значения признаков в отдельных кластерах (группах) со средними значениями в целом по всей совокупности объектов. Если групповые средние существенно отличаются от общего среднего значения, то это может являться признаком хорошего разбиения. Оценка существенности, различий может быть выполнена с помощью t-критерия Стьюдента [6].

Таким образом, для выполнения поставленной задачи был выбран метод «ближайшего соседа» кластерного анализа.

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

Настоящее техническое задание распространяется на разработку приложения для автоматизации процесса формирования отчетов операторов ультрозвуковых установок «Nukem» и «Nordinkraft». Также система должна использоваться для хранения, обработки и анализа данных.

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

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

Создание программной системы позволит обеспечить:

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

Основание для разработки.

Система разрабатывается на основании приказа директора МТИ

№ _____ от «__» __________ _____ года на выпускную квалификационную работу по направлению бакалавра 230100.62 «ИВТ».

Назначение.

Первая версия системы предназначена для формирования отчетов операторов ультрозвуковых установок «Nukem» и «Nordinkraft» на предприятии ООО «Уральская сталь» и поддержки принятия решения о классификации брака на группы с помощью кластерного анализа.

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

Требования к программе или программному изделию.

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

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

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

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

Методическое обеспечение должно быть реализовано в пользовательском интерфейсе системы, который должен предполагать:

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

Требования к надежности.

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

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

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

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

Автоматизированная информационная система должна работать на IBM/PC совместимых персональных компьютерах.

Минимальная конфигурация:

процессор Intel Pentium 800 МГц;
объем оперативного запоминающего устройства 256 Мбайт;
место на жестком диск 50 Мбайт;
сетевая карта Ethernet 100 Мбайт;
монитор с SVGA видеокартой;
клавиатура;
манипулятор «мышь»;
принтер.

Требования к информационной и программной совместимости.

Автоматизированная информационная система должна работать под управлением операционной системы MS Windows 98 или выше на IBM/PC совместимых персональных компьютерах, на которых также должны быть установлен программный продукт MS Office 2003 или выше.

Требования к программной документации.

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

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

В состав сопровождающей документации должны входить:

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

Этапы разработки.

Этапы разработки АИС представлены в таблице 1.1.

Таблица 1.1 – Этапы разработки

Название этапа	Срок	Точность
1 Разработка ядра системы		Описание внутренних форматов, интерфейса и форматов данных базы. Реализация системы на уровне интерфейса.
2 Разработка методов и алгоритмов, кластерного анализа и их реализация		Описание методов и алгоритмов. Программные модули, реализующие методы.
3 Тестирование автоматизированной информационной системы и составление программной документации		Тесты. Документация. Автоматизированная информационная система.

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

Выводы по разделу

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

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

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

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

2 Реализация программного проекта

2.1 Формирование функциональной схемы программных средств

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

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

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

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

Как только SQL сервер получит и обработает запрос, пользователь получит данные о выбранных листах.

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

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

Главное окно ПС или сообщение об ошибке

YZK.mdb

Ввод логина

и пароля

Авторизация

YZK.mdb

Логин

Пароль

Выбор плавки партии даты времени

смены

Данные о листах

YZK.mdb

Формирование отчётов по запросам

Отчёты

Документ

Ответ сервера SQL на запрос

YZK.mdb

Просмотр данных о листах

Данные о листах

YZK.mdb

Данные с клавиатуры

YZK.mdb

Формирование запроса к SQL серверу

Запрос к SQL серверу

YZK.mdb

Формирование исходной матрицы для КА

Матрица исходных значений

Матрица

Считать матрицу

YZK.mdb

А

Начало

Рисунок 2.1 – Функциональная схема

А

Преобразование матрицы

Преобраз-ая матрица

KA.dpr

Матрица

Нормирование матрицы

KA.dpr

Матрица

Нормир-ая матрица

Матрица

Конец

Подбор устра-нимого брака

Выполнить

группировку

Список брако- ванных листов

KA.dpr

Матрица

Рисунок 2.1 – (продолжение)

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

2.2 Выбор и обоснование инструментальных средств разработки

Выбор СУБД.

Проведем теоретический анализ, опираясь на источники литературы и Интернет 3-4 современных СУБД по следующим параметрам:

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

Таким образом, в настоящее время существует большое количество СУБД. Для анализа были отобраны серверные СУБД: InterBase, Microsoft SQL Server, Oracle и настольная – Microsoft Access. Выбор этих СУБД связан с тем, что они наиболее распространены в настоящее время, а также с тем, что уже встречались в работе (кроме Oracle и InterBase). Выбор СУБД для применения зависит от поставленных целей.

Сравнительные характеристики СУБД для персональных компьютеров таблице 2.1.

Для небольшой базы данных с малым числом пользователей вполне подойдет настольная СУБД Microsoft Access. Кроссплатформенностью из рассматриваемых СУБД обладают: InterBase и Oracle, в отличии от двух других СУБД (SQL Server и Access), которые могут работать только под управлением операционной системы Windows.

Таблица 2.1 – Сравнительные характеристики СУБД для персональных компьютеров

Параметры	Название
Параметры	Microsoft SQL Server [7]	InterBase [8]	Microsoft Access [7]	Oracle [9]
1	2	3	4	5
Версия	Microsoft SQL Server 2012	InterBase 2009	Microsoft Access 2007	Oracle Database 11
Фирма производитель	Microsoft Corporation	Borland	Microsoft Corporation	Oracle Corporation
Под управлением, каких ОС функционирует	Windows	- Windows; - Mac OS X; - Linux; - Unix Solaris.	Windows	- Windows; - Mac OS X; - Linux; - Unix.
Требования к аппаратному обеспечению	- Процессор (рекомендуется) 2,0 ГГц и выше - ОЗУ (рекомендуется) не менее 4 ГБ с последующим увеличением по мере роста размера базы данных. - требуется как минимум 6 ГБ свободного места	- процессор Intel x86 - ОЗУ 32 MB - Место на диске 20 MB - Дисковод для чтения дисков CD-ROM	- процессор с тактовой частотой не ниже 500 МГц - ОЗУ не менее 256 МБ. - место на жестком диске 1,5 ГБ	- Процессор минимально Intel x86 1 GHz или x64 1.4 GHz - ОП не ниже 1 Гб - минимальное свободное место на диске 2Гб
Поддерживаемая модель данных	Реляционная модель данных	Реляционная модель данных	Реляционная модель данных	Универсальная модель данных
Поддерживаем-ые объекты БД	- таблицы; - представления; - пользователь; - индекс; - процедура; - функция; - правила; - ограничения; - триггер	- таблицы; - домен; - триггер; - исключения; - курсор; - процедура; - функция;	- таблица; - запрос; - форма; - отчет; - макрос; - модуль	- таблицы; - представления; пользователь; последовательность; - синоним; - индекс; - табличная область; - процедура; - функция; - пакет; - триггер.
Технология создания БД и объектов БД	- визуально; - с использованием SQL-скриптов	- визуально; - с использованием SQL-скриптов	- визуально;	- визуально; - с использованием SQL-скриптов
Поддержка сервера БД	Да	Да	Нет	Да

Продолжение таблицы 2.1

1	2	3	4	5
Средства поддержки ограничений целостности БД	- ключи; - установление связей м/ таблицами - ограничения; - триггер	- ключи; - ограничения (constraint); - триггер; - транзакции	- ключи; - установление связей между таблицами	- ключи; - ограничения (constraint); - триггер; - транзакции
Формат файла (файлов) БД;	.mdf - основной файл (primary); .ndf - вторичный файл (secondary); .ldf - файл журнала транзакций (Transaction Log)	.gdb	.mdb .accdb	- Redo Log Files (Файлы истории отката) - Archive Log Files (Файлы истории архивирования) - Parameter Files (Конфигурационные файлы) - Alert and Trace Log Files (Файлы трассировки и аварийных сообщений); - Alert File или Alert Log (файлы с сообщениями об ошибках) - Backup Files (Файлы резервных копий)
Наличие встроенного языка для разработки приложений	Элементы Microsoft Visual Basic for Application	Базовые языки SQL и Dynamic SQL	Microsoft Access SQL	PL/SQL
Поддержка стандарта SQL	Transact-SQL и MDX	Да	Да	Да
Наличие средств передачи данных в формат MS Excel, MS Word	Только с установкой надстройки Master Data Service для Microsoft Excel	При установке надстройки Data Export for InterBase	Да	- с помощью Oracle Objects for OLE - Пакет TEXT_IO

Продолжение таблицы 2.1

1	2	3	4	5
Наличие средств (каких) для получения отчетов	Да, при установке надстройки служб Microsoft SQL Server 2012 Reporting Services для технологий Microsoft SharePoint 2010	с помощью EMS QuickDesk	Report Wisard	- с использованием SQL-скриптов - Oracle Reports
Возможность реализации прав доступа для отдельных пользователей (роли и привилегии)	с помощью объекта «пользователь (user)», назначение им привилегий	Команды: - роль (role) - grant и revoke	Мастер защиты	- роль (role) - grant и revoke - с помощью объекта «пользователь (user)», назначение им привилегий
Наличие встроенных средств для создания резервной копии БД и восстановления БД из резервной копии	Да	Да	Да	Плагин «Oracle backup and Recovery»
Простота/ сложность работы с СУБД	Сложно	Просто	Просто	Сложно

Наиболее требовательна к ресурсам СУБД Microsoft SQL Server. В то время как Oracle при более умеренных системных требованиях предоставляет больше поддерживаемых объектов. Самыми низкими системными требованиями из представленных СУБД обладает InterBase.

Все из представленных СУБД имеют возможность передачи данных в формат MS Excel, MS Word, но SQL Server и InterBase требуют установки дополнительной надстройки. Наиболее удобное средство для получения отчета имеется в Microsoft Access.

Возможность реализации прав доступа для отдельных пользователей (ролей и привилегий) плохо реализована в СУБД Microsoft Access, в остальных же сравниваемых СУБД эта возможность реализована достаточно хорошо. По остальным характеристикам выбранные СУБД находятся примерно на одном уровне, но для данной работы наиболее приемлемой СУБД является Microsoft SQL Server.

Выбор средств разработки приложения.

Проведем теоретический анализ, опираясь на источники литературы и Интернет доступных современных инструментальных средств для разработки приложений АИС (2-3) по следующим критериям:

название, версия, фирма производитель, под управлением каких ОС функционирует (зависимость от платформы);
подход к разработке программного обеспечения (структурный, объектно-ориентированный)
механизмы доступа к БД;
утилиты для работы с БД;
поддержка стандарта языка SQL;
наличие компонент для работы с БД (невизуальные и визуальные компоненты);
наличие компонент построения отчетов и диаграмм;
поддержка Windows-подобного (оконного) интерфейса;
средства поддержки транзакций (параллельная работа нескольких пользователей с БД);
простота/ сложность работы с инструментальным средством;
возможность создания запускаемого файла.

Таким образом для анализа были отобраны средства разработки: Borland Delphi 7, C++ Builder 6, Microsoft Visual Studio 2010, как наиболее популярные. Все три средства обладают большими возможностями для создания приложений, организующих взаимодействие с базами данных. Microsoft Visual Studio 2010 является не только наиболее мощным инструментом для разработки приложений, но и более требовательным к параметрам системы.

Сравнительные характеристики средств разработки приложений 2.2.

Таблица 2.2 – Сравнительные характеристики средств разработки приложений

Параметры	Название
Параметры	Borland Delphi [10]	Borland C++ Builder [10]	Microsoft Visual Studio [7]
1	2	3	4
Версия	Borland Delphi 7	Borland C++ Builder 6	Microsoft Visual Studio 2010
Фирма производитель	Borland	Borland	Microsoft Corporation
Под управлением каких ОС функционирует	Windows XP и выше	Windows XP и выше	Windows XP и выше
Подход к разработке программного обеспечения	Объектно-ориентированный	Объектно-ориентированный	Объектно-ориентированный
Механизмы доступа к БД	BDE, ADO, IBX [1]	BDE, ADO, IBX	ADO.NET, LINQ, IBX
Поддержка стандарта языка SQL	да	Да	да
Наличие компонент для работы с БД	Визуальные и невизуальные	Визуальные и невизуальные	Визуальные и невизуальные

Продолжение таблицы 2.2

1	2	3	4
Утилиты для работы с БД	- Database Desktop; - BDE Administrator; - SQL Explorer; - SQL Monitor	- Database Desktop; - BDE Administrator; - SQL Explorer; - SQL Monitor	- Solution Explorer; - Server Explorer; - Data Base Diagram Designer; - Table Designer; - Query and View Designer
Наличие компонент построения отчетов и диаграмм	элементы системы Rave Reports Borland Editions	элементы системы Quick Reports	- Crystal Reports Windows Forms Viewer; - Crystal Reports Engine
Поддержка Windows-подобного (оконного) интерфейса	да	Да	Да
Средства поддержки транзакций	имеются	имеются	имеются
Простота/ сложность работы с инструментальным средством	просто	просто	просто
Возможность создания запускаемого файла	да	Да	да

Выбор инструментальных средств для разработки системы зависит от целей разрабатываемой системы. После тщательного анализа было выбрано средство разработки Borland Delphi 7, так как отвечает основным предъявляемым требованиям – простоте в эксплуатации и низким системным требованиям, кроме того, выбранная СУБД Microsoft SQL Server полностью интегрируется с Borland Delphi 7. Выбор инструментальных средств для разработки системы БД осуществляется при условии, что существует достаточное финансирование для покупки инструментальных средств.

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

Borland Delphi – это среда разработки программ, ориентированных на работу в операционных системах семейства Windows. Программы в Delphi создаются на основе современной технологии визуального проектирования которая, в свою очередь, базируется на идеях объектно-ориентированного программирования. Программы в Delphi пишутся на языке Object Pascal, который является преемником и развитием языка Turbo Pascal. Основное назначение Delphi – служит средством для быстрого создания широкого класса Windows – приложений. Она учитывает многие новейшие достижения в программировании и практике создания приложений и предназначена для визуального программирования, когда разработчик видит большую часть результатов непосредственно на экране монитора уже в процессе своей работы по созданию программы. Визуальное программирование позволяет быстрее создавать интерфейс программы, сделать его более качественным за счет наилучшего расположения информации на экране монитора, избежать многих ошибок уже на этапе проектирования.

Delphi позволяет решать множество задач, в частности:

создавать законченные приложения под Windows самой различной направленности, от чистого вычислительных и логических, до графических и мультимедиа;
быстро создавать профессионально выглядящий оконный интерфейс, удовлетворяющий всем требованиям Windows;
создавать мощные системы работы с локальными и удаленными базами данных любых типов; при этом имеются средства автономной отладки приложений с последующим выходом в сеть;
создавать многозвенные распределенные приложения, основанные на различных технологиях;
создавать приложения, которые управляют другими приложениями, в частности такими программами Microsoft Office, как Word, Excel и другие;
создавать кросс-платформенные приложения, которые можно компилировать и эксплуатировать как в системе Windows, так и в системе Linux;
создавать приложения различных классов для работы в Интернет;
создавать профессиональные программы установки для приложений Windows, учитывая всю специфику и все требования Windows;
создание отчетов, справочных систем, библиотек DLL, компонентов ActiveX и т.д.

Все эти достоинства обусловили выбор инструментальной среды Delphi и языка программирования Object Pascal как средства разработки.

При проектировании ПС использовались CASE-средства Rational Rose 2003 Enterprise Edition. Rational Rose – это Case-средство, предназначенное для анализа и проектирования объектно-ориентированных программных систем.

Выбор Case-средства визуального объектно-ориентированного проектирования информационных систем Rational Rose 2006 Enterprise Edition, определялся рядом возможностей данного Case-средства:

имеет удобный для пользователя графический интерфейс;
многоплатформенность;
проектирование систем любой сложности;
развернутое представление о проекте в сочетании со средствами документирования (SoDA);
возможность проведения обратного проектирования имеющихся систем;
непосредственная работа (инжиниринг и реинжиниринг) с исполняемыми модулями и библиотеками форматов EXE, DLL, TLB, OCX;
поддержка технологий MTS (Microsoft Transaction Server) и ADO (ActiveX Data Objects) на уровне шаблонов и исходного кода, а также элементов стратегической технологии Microsoft – СОМ+ (DCOM);
поддержка языка UML.

Унифицированный язык моделирования (Unified Modeling Language – UML) это язык для специфицирования, визуализации, конструирования программных систем, а так же бизнес моделей и прочих не программных систем.

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

2.3 Проектирование базы данных

Иерархия функций.

Внешний уровень является уровнем пользователей СУБД, т.к. он является уровнем восприятия каждого пользователя. В принципе для каждого пользователя создается свой внешний уровень (схема - модель с соответствующим языком описания данных). Типичным воплощением внешнего уровня является использование представлений в языке SQL [15].

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

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

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

Иерархия функций, реализуемая системой, представлена на рисунке 2.2.

Формирование отчётов

Проценты проверенной продукции на «NUKEM» от «NordinKraft»

Выбор плавки

1

Выбор поиска за смену

АИС

Соединение с БД

Выбор УЗК «нукем»

Выбор поиска данных по дате

Выбор даты

Выбор поиска по плавке

Выбор плавки

Выбор даты и смены

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

Выбор даты и времени

Выбор поиска по дате и плавке

Выбор даты и плавки

Поиск

Выбор поиска по плавке и партии

Выбор плавки и партии

Рисунок 2.2 – Иерархия функций

Кластерный анализ – кластеризация брака на исправимый неисправимый

Выбор периуда

Выбор поиска за смену

Выход

Формирование отчётов

1

АИС

Выбор УЗК «север»

Выбор поиска данных по дате

Выбор даты

Выбор поиска по плавке

Выбор плавки

Выбор даты и смены

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

Выбор даты и времени

Выбор поиска по дате и плавке

Выбор даты и плавки

Поиск

Выбор поиска по плавке и партии

Выбор плавки и партии

Рисунок 2.2 – (продолжение)

Формализованное описание предметной области.

Формализованное описание предметной области содержит описание классов объектов (сущностей), выявленных на этапе анализа предметной области и связей (отношений) между ними. Оно необходимо для того, чтобы определить, какие данные будут в таблицах разрабатываемой БД, а также логические ограничения полей таблиц [11].

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

Таблица 2.3 – Классы объектов предметной области, свойства

Класс объектов/ Свойство	Ключ (уникальный, первичный)	Физические характеристики (тип, длина)	Обязательность значения (м.б., д.б.)	Логические ограничения	Процессы (генерация, ввод значений, возможность обновления, просмотра)
1	2	3	4	5	6
Плавка «Север»
Код Плавки	УИ1 П	число 4	д.б.	>0	Г, Пр
Плавка		символ 50	д.б.		Вв, Пр, Об
Сорт Стали		символ 50	д.б.		Вв, Пр, Об
Партия «Север»
Код Парти	УИ1 П	число 4	д.б.	>0	Г, Пр
Код плавки	УИ2	число 4	д.б.	>0	Г, Пр
Партия		символ 50	д.б		Вв, Пр, Об
Класс поверхности		число 2	д.б.		Вв, Пр, Об
Класс края		число 2	д.б.		Вв, Пр, Об
Заказ		символ 50	д.б.		Вв, Пр, Об
Листы «Север»
Код листа	УИ1 П	число 4	д.б.	>0	Г, Пр
Код Парти	УИ2	число 4	д.б.	>0	Г, Пр
Код бригады	УИ3	число 4	д.б.	>0	Г, Пр
Код смены	УИ4	число 4	д.б.	>0	Г, Пр
Лист		число 2	д.б.		Вв, Пр, Об
Длинн		число 2	д.б.		Вв, Пр, Об
Ширина		число 2	д.б.		Вв, Пр, Об
Толщина		число 2	д.б.		Вв, Пр, Об
Температура		число 2	д.б.		Вв, Пр, Об
Без контроля		логическое 1			Вв, Пр, Об
Оператор сказал годен		логическое 1			Вв, Пр, Об
дата		Datum 4	д.б.		Вв, Пр, Об
Ручной контроль		логическое 1	д.б.		Вв, Пр, Об

Продолжение таблицы 2.3

1	2	3	4	5	6
Бригада «Север»
Код бригады	УИ1 П	число 4	д.б.	>0	Г, Пр
Бригада		символ 50	д.б		Вв, Пр, Об
Смены
Код смены	УИ1 П	число 4	д.б.	>0	Г, Пр
Начало смены		число 2	д.б		Вв, Пр, Об
Конец смены		число 2	д.б		Вв, Пр, Об
Плавка «Нукем»
Код Плавки	УИ1 П	число 4	д.б.	>0	Г, Пр
Плавка		символ 50	д.б.		Вв, Пр, Об
Сорт Стали		символ 50	д.б.		Вв, Пр, Об
Партия «Нукем»
Код Парти	УИ1 П	число 4	д.б.	>0	Г, Пр
Код плавки	УИ2	число 4	д.б.	>0	Г, Пр
Партия		символ 50	д.б		Вв, Пр, Об
Класс поверхности		число 2	д.б.		Вв, Пр, Об
Класс края		число 2	д.б.		Вв, Пр, Об
Заказ		символ 50	д.б.		Вв, Пр, Об
Листы «Нукем»
Код листа	УИ1 П	число 4	д.б.	>0	Г, Пр
Код Парти	УИ2	число 4	д.б.	>0	Г, Пр
Код бригады	УИ3	число 4	д.б.	>0	Г, Пр
Код смены	УИ4	число 4	д.б.	>0	Г, Пр
Лист		число 2	д.б.		Вв, Пр, Об
Длинн		число 2	д.б.		Вв, Пр, Об
Ширина		число 2	д.б.		Вв, Пр, Об
Толщина		число 2	д.б.		Вв, Пр, Об
Температура		число 2	д.б.		Вв, Пр, Об
Без контроля		логическое 1			Вв, Пр, Об
Оператор сказал годен		логическое 1			Вв, Пр, Об
дата		Datum 4	д.б.		Вв, Пр, Об
Ручной контроль		логическое 1	д.б.		Вв, Пр, Об
Бригада «Нукем»
Код бригады	УИ1 П	число 4	д.б.	>0	Г, Пр
Бригада		символ 50	д.б		Вв, Пр, Об

В таблице 2.3 использованы сокращения: УИ – уникальный идентификатор, П – кандидат в первичный ключ (главный уникальный идентификатор), Г – генерация значения, Вв – ввод значения, Пр – просмотр значения, Об – обновление значения, м.б. – может быть; д.б. – должно быть.

Связи между описанными классами объектов представлены в таблице 2.4.

Таблица 2.4 связи между классами

Классы объектов		Опциональность связи		Имя связи со стороны		Тип связи со стороны
главн. КО	подч. КО	глав. КО	подч. КО	главн. КО	подч. КО	Главн. КО	Подч. КО
ПАРТИЯ НУКЕМ	ПЛАВКА НУКЕМ	Д.Б.	Д.Б.	соответствует	имеет	1	М
ПАРТИЯ СЕВЕР	ПЛАВКА СЕВЕР	Д.б.	Д.б.	соответствует	имеет	1	М
ЛИСТЫ НУКЕМ	ПАРТИЯ НУКЕМ	Д.б.	Д.б.	соответствует	имеет	1	М
ЛИСТЫ СЕВЕР	ПАРТИЯ СЕВЕР	Д.б.	Д.б.	соответствует	имеет	1	М
ЛИСТЫ НУКЕМ	БРИГАДА НУКЕМ	Д.б.	Д.б.	фиксирует	содержит	1	М
ЛИСМТЫ СЕВЕР	БРИГАДА СЕВЕР	Д.б.	Д.б.	фиксирует	содержит	1	М
ЛИСТЫ НУКЕМ	СМЕНЫ	Д.б.	Д.б.	фиксирует	содержит	1	М
ЛИСТЫ СЕВЕР	СМЕНЫ	Д.б.	Д.б.	фиксирует	содержит	1	М

В таблице 2.4 использованы сокращения: М.б. – может быть; Д.б. – должно быть; главн. – главный; подч. – подчиненный.

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

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

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

Описание состава пользователей и их уровни доступа оформляются в таблице 2.5.

Таблица 2.5 – Уровни доступа к БД пользователей АИС

Классы объектов свойства	Пользователи
Классы объектов свойства	Прикладной программист	Конечный пользователь – оператор
Плавка «Нукем» и «Север»
Код Плавки	RIUD	-
Плавка	RIUD	R
Сорт Стали	RIUD	R
Партия «Нукем» и «Север»
Код Парти	RIUD	-
Код плавки	RIUD	R
Партия	RIUD	R
Класс поверхности	RIUD	R
Класс края	RIUD	R
Заказ	RIUD	R
Листы «Нукем» и «Север»
Код листа	RIUD	-
Код Парти	RIUD	R
Код бригады	RIUD	R
Код смены	RIUD	R
Лист	RIUD	R
Длинн	RIUD	R
Ширина	RIUD	R
Толщина	RIUD	R
Температура	RIUD	R
Без контроля	RIUD	R
Оператор сказал годен	RIUD	R
дата	RIUD	R
Ручной контроль	RIUD	R
Бригада «Нукем» и «Север»
Код бригады	RIUD	-
Бригада	RIUD	R
Смены
Код смены	RIUD	-
Начало смены	RIUD	R
Конец смены	RIUD	R

Перекрестная проверка модели предметной области и иерархии функций представлена в таблице 2.6.

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

Исходными данными для построения информационно-логической модели предметной области (ИЛМ) являются результаты анализа предметной области, представленные в виде описания классов объектов и связей между ними. Чаще всего ИЛМ предметной области представляют в терминах семантической модели данных, в виде ER-диаграммы предметной области [11].

Концептуальная инфологическая модель предметной области, построенная по методологии Ричарда Баркера, представлена в приложении А.

В настоящее время существуют разнообразные нотации построения ER-модели. Подробно рассмотрим самую распространённую из них – методологию Ричарда Баркера [11].

Методология Ричарда Баркера построена на базе следующих элементов: класс объектов, свойство класса объектов, уникальные идентификаторы, опциональность свойств, мощность (тип), опциональность, уникальность объектов из связей, супертипы, подтипы, арки [11].

В методологии используются следующие соглашения:

класс объектов отображается в виде четырехугольника с закругленными углами, а имя класса объектов указывается внутри четырехугольника, это имя существительное в единственном числе, отображенное заглавными буквами;
свойства записываются внутри четырехугольника, отображающего класс объектов строчными буквами, это имя существительное в единственном числе;
четырехугольник, отображающий класс объектов, можно увеличивать до любых размеров, четырехугольники могут быть разных размеров;
опциональность свойств помечается: обязательное свойство – звездочкой (*), необязательное – кружочком (о);
уникальный идентификатор помечается #;
обязательная связь помечается сплошной линией, необязательная связь пунктирной линией;
тип (мощность) связи «один» помечается линией, «много» — «вороньей лапой».

Необходимо провести проверку между моделью данных и иерархией функций. Перекрестную проверку можно представить в виде таблицы 2.6.

Таблица 2.6 - Перекрестная проверка модели предметной области и иерархии функций

Функции	Классы объектов
Функции	1	2	3	4	5	6	7	8	9
1	2	3	4	5	6	7	8	9	10
1	I
2	U
3	D
4	R
5		I
6		U
7		D

Продолжение таблицы 2.6

1	2	3	4	5	6	7	8	9	10
8		R
9			I
10			U
11			D
12			R
13				I
14				U
15				D
16				R
17					I
18					U
19					D
20					R
21						I
22						U
23						D
24						R
25							I
26							U
27							D
28							R
29								I
30								U
31								D
32								R
33									I
34									U
35									D
36									R

В таблице 2.6 использованы сокращения операций, осуществляемых с данными: R – read (чтение); I – insert (добавление); U – update (обновление); D – delete (удаление). Также использованы сокращения классов объектов:

КО1 – ПАРТИЯ СЕВЕР;
КО2 – ПАРТИЯ НУКЕМ;
КО3 – ПЛАВКА СЕВЕР;
КО4 – ПЛАВКА НУКЕМ;
КО5 – ЛИСТ СЕВЕР;
КО6 – ЛИСТ НУКЕМ;
КО7 – БРИГАДА СЕВЕР;
КО8 – БРИГАДА НУКЕМ;
КО9 – СМЕНА.

В таблице 7 использованы сокращения функций:

Ф1 – Добавление плавки север;
Ф2 – Обновление плавки север;
Ф3 – Удаление типа по плавке север;
Ф4 – Просмотр плавке север;
Ф5 – Добавление плавки нукем;
Ф6 – Обновление плавки нукем;
Ф7 – Удаление по плавки нукем;
Ф8 – Просмотр плавки нукем;
Ф9 – Добавление партии север;
Ф10 – Обновление партии север;
Ф11 – Удаление по партии север;
Ф12 – Просмотр партии север;
Ф13 – Добавление партии нукем;
Ф14 – Обновление партии нукем;
Ф15 – Удаление по партии нукем;
Ф16 – Просмотр партии нукем;
Ф17 – Добавление листа север;
Ф18 – Обновление листа север;
Ф19 – Удаление листа север;
Ф20 – Просмотр листа север;
Ф21 – Добавление листа нукем;
Ф22 – Обновление листа нукем;
Ф23 – Удаление листа нукем;
Ф24 – Просмотр листа нукем;
Ф25 – Добавление бригады север;
Ф26 – Обновление бригады север;
Ф27 – Удаление бригады север;
A28 – Просмотр бригады север;
Ф29– Добавление бригады нукем;
Ф30 – Обновление бригады нукем;
Ф31 – Удаление бригады нукем;
Ф32 – Просмотр бригады нукем;
Ф33 – Добавление смены;
Ф34 – Обновление смены;
Ф35 – Удаление смены;
Ф36 – Просмотр смены.

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

Исходными данными для построения ИЛМ предметной области являются результаты анализа предметной области, представленные в виде описания классов объектов и связей между ними. Чаще всего ИЛМ предметной области представляют в терминах семантической модели данных, в виде ER — диаграммы предметной области. В настоящее время существуют разнообразные методологий (нотации) построения ER—модели. Построим инфологическую модель базы данных в виде ER-диаграммы по методологии Ричарда-Баркера. Полученная ER-диаграмма представлена на рисунке 2.3.

БРАК

#*Код брака

*вид брака

*сколько брака

Листы «Север»

#* Код листа

* Код Партия

* Код бригады

* Код смены

* Лист

* Длинна

* Ширина

* Толщина

* Температура

* Без контроля

* Оператор сказал годен

* дата

* Ручной контроль

Бригады

«Север»

#* Код бригады

* Бригада

Плавка «Север»

#* Код плавки

* Плавка

* Сорт стали

Партия «Север»

#* Код Парти

* Код плавки

* Партия

* Класс поверхности

* Класс края

* Заказ

Бригады

«Нукем»

#* Код бригады

* Бригада

Листы «Нукем»

#*Код листа

* Код Партия

* Код бригады

* Код смены

* Лист

* Длинна

* Ширина

* Толщина

* Температура

* Без контроля

* Оператор сказал

* Годен или брак

* дата

* Ручной контроль

Плавка «нукем»

#* код плаки

* Плавка

* Сорт стали

СМЕНЫ

#* Код смены

* Начало смены

* Конец смены

Партия «Нукем»

#*Код Парти

* Код плавки

* Партия

* Класс поверхности

* Класс края

* Заказ

Рисунок 2.3 – ER-диаграмма

Пояснение к диаграмме изображенной на рисунке 2.3. Класс объектов отображен в виде четырехугольника с закругленными углами. Имя и свойства класса объектов указано внутри четырехугольника. Опциональность свойств: обязательные свойства обозначены (*); первичные ключи обозначены знаком (#). Опциональность связей: обязательная связь отмечена сплошной линией, необязательная пунктиром, тип (мощность) связи «один» отмечена линией, «много» — «вороньей лапой» [18].

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

В ходе проектирования было произведено преобразование инфологической модели в даталогическую модель, построенной на основе реляционной модели данных [19]. Классы объектов преобразуются в таблицы, а связи приводят к появлению внешних ключей. Даталогическая модель представлена на рисунке 2.4.

Рисунок 2.4 – Даталогическая модель

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

Также верно, что каждая таблица имеет уникальное ключевое поле, которое однозначно определяет любое не ключевое, т.е. запись ему соответствующую. Что в совокупности с соответствием первой нормальной форме является соответствием второй нормальной форме (2НФ).

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

Также верно, что каждая таблица имеет уникальное ключевое поле, которое однозначно определяет любое не ключевое, т.е. запись ему соответствующую. Что в совокупности с соответствием первой нормальной форме является соответствием второй нормальной форме (2НФ).

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

Этап физического проектирования заключается в увязке логической структуры БД и физической среды хранения с целью наиболее эффективного размещения данных, т.е. отображении логической структуры БД в структуру хранения. Решается вопрос размещения хранимых данных в пространстве памяти, выбора эффективных методов доступа к различным компонентам «физической» БД. Физическая модель БД представлена на языке описания данных СУБД SQL Server [20]. Результаты этого этапа документируются в форме схемы хранения на языке определения хранимых данных [12]. Принятые на этом этапе решения оказывают определяющее влияние на производительность программного средства. Рассмотрим каждый из классов объектов в виде таблиц 2.7 – 2.16.

Таблица 2.7 - Реляционная таблица «ChargenNuk»

Название поля	Ключ	Тип, длина	Опц-ть	Логич. огранич.	Примеры данных
idCharge	primary key	числовой	not null	-	10691
ChargenNr		текстовый	not null	-	Ю62522Л
StahlSorte		текстовый	not null	-	К60-2

Таблица 2.8 - Реляционная таблица «PartieNk»

Название поля	Ключ	Тип, длина	Опц-ть	Логич. огранич.	Примеры данных
idPartie	primary key	Числовой	not null		54121
refCharge	foreign key	числовой	not null		34617
partieNr		текстовый	not null		779Т
KlassInen		числовой	not null		1
KlassRand		числовой	not null		2
AuftragNr		числовой	not null		2222000691

Таблица 2.9 - Реляционная таблица «ChargenNk»

Название поля	Ключ	Тип, длина	Опц-ть	Логич. огранич.	Примеры данных
idCharge	primary key	числовой	not null	-	10691
ChargenNr		текстовый	not null	-	Ю62522Л
StahlSorte		текстовый	not null	-	К60-2

Таблица 2.10 - Реляционная таблица «BrigadeNuK»

Название поля	Ключ	Тип, длина	Опц-ть	Логич. огранич.	Примеры данных
idBrigade	primary key	числовой	not null	-	1
Brigadename		текстовый	not null	-	Бригада 1

Таблица 2.11 - Реляционная таблица «PartieNuk»

Название поля	Ключ	Тип, длина	Опц-ть	Логич. огранич.	Примеры данных
idPartie	primary key	Числовой	not null		54121
refCharge	foreign key	числовой	not null		34617
partieNr		текстовый	not null		779Т
KlassInen		числовой	not null		1
KlassRand		числовой	not null		2
AuftragNr		числовой	not null		2222000691

Таблица 2.12 - Реляционная таблица «Braсk»

Название поля	Ключ	Тип, длина	Опц-ть	Логич. огранич.	Примеры данных
idBrack	primary key	Числовой	not null		54
ArtderEhe		числовой	not null		3
Anzahl		числовой	not null		44.32

Таблица 2.13 - Реляционная таблица «BrigadeNK»

Название поля	Ключ	Тип, длина	Опц-ть	Логич. огранич.	Примеры данных
idBrigade	primary key	числовой	not null	-	1
Brigadename		текстовый	not null	-	Бригада 1

Таблица 2.14 - Реляционная таблица «Schicht»

Название поля	Ключ	Тип, длина	Опц-ть	Логич. огранич.	Примеры данных
idSchicht	primary key	числовой	not null	-	1
von		числовой	not null	-	8
bis		числовой	not null		20

Таблица 2.15 - Реляционная таблица «BleachNuk»

Название поля	Ключ	Тип, длина	Опц-ть	Логич. огранич.	Примеры данных
1	2	3	4	5	6
idBleach	primary key	числовой	not null	-	1034462
refPartie	foreign key	числовой	not null	-	54121
refBrigade	foreign key	числовой	not null	-	3
refSchicht	foreign key	числовой	not null	-	2
BleachNr		числовой	not null	-	3
Lange		числовой	not null	-	7037
Breite		числовой	not null	-	2599
Dicke		числовой	not null	-	17

Продолжение таблицы 2.15

1	2	3	4	5	6
Temp		числовой	not null	-	33
Ungeprueft		логическое	not null	-	0
Freigegeben		логическое	not null	-	1
Datum		дата	not null	-	05.08.2005 13:34:00
Markierung		числовой	not null	-	0
Handprf		логическое	not null	-	1

Таблица 2.16 - Реляционная таблица «BleachNk»

Название поля	Ключ	Тип, длина	Опц-ть	Логич. огранич.	Примеры данных
idBleach	primary key	числовой	not null	-	1034462
refPartie	foreign key	числовой	not null	-	54121
refBrigade	foreign key	числовой	not null	-	3
refSchicht	foreign key	числовой	not null	-	2
BleachNr		числовой	not null	-	3
Lange		числовой	not null	-	7037
Breite		числовой	not null	-	2599
Dicke		числовой	not null	-	17
Temp		числовой	not null	-	33
Ungeprueft		логическое	not null	-	0
Freigegeben		логическое	not null	-	1
Datum		дата	not null	-	05.08.2005 13:34:00
Handprf		логическое	not null	-	1

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

2.4 Разработка алгоритмов

Для реализации математического аппарата разрабатываемой АИС был выбран кластерный анализ, метод поиска сгущений. Данный метод реализован в программе в виде модуля KA.pas. Схема работы алгоритма кластерного анализа представлена на рисунка 2.5.

Основные этапы алгоритма кластерного анализа:

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

Рисунок 2.5 – Диаграмма деятельности кластерного анализа

На рисунке 2.6 представлен укрупнённый алгоритм программного средства.

Начало

По плавке и партии

По дате и времени

1

Начало

Ввод пароля

Успешно

нет

Главная форма

Сообщение

Вкладка

1 Выбор УЗК нукем

2 Выбор УЗК север

3 Выбор процентов проверенного

4 Выбор Анализ брака

5 Выход

Критерий

да

1 По дате

2 По плавке

3 По партия

4 За смену

5 По дате и времени

6 По плавке и партии

7 к главной форме

По плавке

По дате

По партия

За смену

1

3

4

5

2

А

7

Б

А

С

Б

Выбор УЗК нукем

6

Рисунок 2.6 – Укрупнённый алгоритм ПС

Конец

2

По плавке и партии

По дате и времени

4

3

С

Критерий

1 По дате

2 По плавке

3 По партия

4 За смену

5 По дате и времени

6 По плавке и партии

7 к главной форме

По плавке

По дате

По партия

За смену

1

3

4

5

2

А

7

D

Выбор УЗК Север

6

D

1 Выбор плавки из списка

2 К главной форме

Конец

Критерий

Кластерный анализ

1 Выбор даты и смены

2 К главной форме

А

2

F

1

F

Критерий

Проценты

А

2

E

1

E

Проценты от проверенных

Кластерный анализ

Рисунок 2.6 – (продолжение)

2.5 Тестирование разработанного программного средства

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

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

Тестирование программного средства – это процесс выполнения его программ на некотором наборе данных, для которого заранее известен результат применения. Такой набор данных называется тестом [14].

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

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

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

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

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

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

Основные принципы тестирования:

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

Существуют так называемы заповеди отладки Майерса:

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

Пропускайте заново все тесты, если в неё были внесены изменения [21].

Для проверки правильности работы программы воспользуемся программным средством MS Excel. На рисунке 2.7 представлены входные данные для расчета с помощью MS Excel. Слева данные в програмном средстве, а справа теже данные, но в MS Excel.

Рисунок 2.7 – Входные данные

Далее на рисунках 2.8 показаны расчёты в MS Excel.

Рисунок 2.8 – Расчёты в MS Excel

Рисунок 2.8 – (продолжение)

На рисунке 2.9 представлен результат работы програмного средства.

Рисунок 2.9 – Результат в программном средстве

Как видно из рисунков 2.8 и 2.9 списки листов полученных при расчетах в MS Excel совпадают со списками, полученными с помощью программного средства.

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

Выводы по разделу

Выполнены следущие задачи:

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

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

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

4 Проведено тестирование программного средства на тестовом наборе данных.

3 Технологический раздел

3.1 Разработка руководства системного программиста

Программное средство позволит:

облегчить выборку данных;
просматривать данные с любого компьютера внутренней сети предприятия зная логин и пароль;
снизить временные затраты и трудоемкость осуществления аналитической обработки данных, и формирования отчётов;
программное средство позволит повысить эффективность работы операторов УЗК «Nukem» и «Nordinkraft».

Для корректной работы программного средства аппаратное обеспечение должно состоять как минимум из следующих компонент: процессор с тактовой частотой не ниже 800 Mhz , оперативная память объёмом не менее 256 Mb, место на жёстком диске 50 Mb, видеоадаптер с видеопамятью не меньше 32 Mb. В случае если на рабочем месте используется операционная система, требующая большие характеристики, требования к программному средству будет соответствовать минимальным требованиям к операционной системе.

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

АИС имеет модульную структуру и состоит из проекта Project.dpr, в который входят модули: Unit1.pas, Unit2.pas, Unit3.pas, Unit4.pas, Unit5.pas и КА.pas.

Также имеются файлы с расширением *.dfm (хранят описание содержимого окна формы) и *.dcu (результат преобразования в машинную инструкцию текста из обоих файлов). Файлы *.dcu создаются компилятором и дают необходимую базу для работы компоновщика, который преобразует их в единый загружаемый файл UZK.exe.

Настройка программы требуется если его адрес изменился. Для этого требуется открыть компонент UZK: TADOConnection.ConnectionString. Появится диалоговое окно «Свойства канала передачи данных» представленное на рисунке 3.1.

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

Рисунок 3.1 – Свойства канала передачи данных

Резервное копирование и восстановление БД.

Запускаем Enterprise Manager.

Разворачиваем дерево и выбираем сервер, для которого будем настраивать резервное копирование, щелкаем правой кнопкой мыши и выбираем Cвойства (Properties), на первой закладке устанавливаем галочку Autostart SQL Server Agent.

Чтобы не перезагружать сервер, запустим SQL Server Agent вручную. Для этого разворачиваем папку Management и запускаем Agent правой кнопкой мыши, выбрав Start в выпадающем меню.

Переходим к пункту Database Maintenance (ниже в той же папке) и щелкнув ПКМ в свободной области справа выбираем New Maintenance Plan, запустится мастер. Сначала выберем базы, для которых будет действовать этот план (планов может быть несколько), можно выбрать все базы, только системные, только пользовательские или произвольно.

Следующие несколько закладок просто пролистываем, пока не доберемся до Specify the Database Backup Plan. Здесь оставляем все по умолчанию и переходим к настройке расписания нажав кнопку Change.

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

На закладке Specify the Transaction Log Backup Plan аналогичным образом настраиваем резервное копирование лога транзакций, задаем ему расписание и место хранения, если баз много советуем разнести резервное копирование баз и логов по времени. Копирование лога транзакций не является обязательным, однако его наличие позволяет откатить базу на произвольное время с момента создания предыдущей копии, что очень удобно, нужное время довольно быстро находится последовательным делением временного промежутка пополам.

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

Теперь разворачиваем SQL Server Agent и выбрав пункт Jobs убеждаемся в наличии там двух заданий. Запускаем их вручную (ПКМ - Start Job) и проверяем правильность выполнения. Все, можем спать спокойно, резервное копирование настроено.

Для восстановления базы из резервной копии щелкаем на нужной базе правой кнопкой мыши и выбираем Все задачи - Restore Database.

В открывшемся окне указываем дату и внизу выбираем необходимый архив. Если есть копия лога транзакций, то доступна опция Point in time restore, с помощью которой можно выбрать момент времени, на который требуется восстановить базу.

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

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

3.2 Руководство пользователя

Автоматизированная информационная система формирования отчётов операторов УЗК «Nukem» и «Nordinkraft». предназначена для автоматизации процесса формирования отчётов о проверенном листовом прокате, а также анализ брака листового проката. Внедрение АИС позволит:

облегчить выборку данных;
просматривать данные, с любого компьютера внутренней сети предприятия зная логин и пароль;
снизить временные затраты и трудоемкость осуществления аналитической обработки данных, и формирования отчётов;
программное средство позволит повысить эффективность работы операторов УЗК «Nukem» и «Nordinkraft».

Для функционирования автоматизированной информационной системы необходимо иметь компьютер с тактовой частотой процессора не менее 800 МГц, объемом оперативной памяти – 256 Мб, объемом свободного места на диске – 50 Мб. Также должна быть установлена операционная система не ниже Windows 98.

Так как АИС предназначена для работы в среде Windows, то монитор компьютера должен быть типа VGA.

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

Так как программой формируются выходные документы в формате MS Word, то для их распечатки необходим принтер.

Для работы с базой данных на компьютере должна быть установлена MS Word пакета MS Office 2003 и выше.

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

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

Рисунок 3.2 – Авторизация пользователя

Если пароль верен, то на экране появится главное окно программы. Главная форма представлена на рисунке 3.3.

Рисунок 3.3 – Главное окно программы

Выберите нужную вкладку:

«Север»;
«Нукем»;
«% от севера»;
«Анализ».

Если вы выбрали Север или Нукем, то дальнейшая работа с программным средством зависит от того, какой из пунктов будет выбран. Выберите нужный вам критерий из представленных на рисунке 3.4. После чего нажмите «ОК»

Рисунок 3.4– Выбор критерия отбора

В зависимости от выбора критерия, справа появиться новая панель, на которой вам потребуется выбрать период времени, дату, плавку, партию или смену. Панели представлены на рисунках 3.5-3.10.

Рисунок 3.5 – Критерий по дате

Рисунок 3.6 – Критерий по плавке

Рисунок 3.7 – Критерий за смену

Рисунок 3.8 – Критерий по дате и времени

Рисунок 3.9 – Критерий по дате и плавке

Рисунок 3.10 – Критерий по плавке и партии

После выбора параметров требуется нажать кнопку «Вывести». После произведённых манипуляций таблица в центре главного окна заполнится данными о листах. Пример представлен на рисунке 3.11.

Рисунок 3.11 – Пример просмотра данных о проверенных листах

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

Рисунок 3.12 – Протокол полистного контроля по дате

Рисунок 3.13 – Пример отчёта

Если была выбрана вкладка % от севера, то главное окно приобретёт вид представленный на рисунке 3.14.

Рисунок 3.14 - Главная форма вкладка % от севера

На панели, представленной на рисунке 3.15, выберите плавку и нажмите кнопку «Вывести». Таблицы заполнятся, а внизу появится проценты повторно проверенного листового проката рисунок 3.16.

Рисунок 3.15 – Выбор плавки

Рисунок 3.16 – Заполненная главная форма вкладка % от севера

Если выбрана вклада анализ, то главное окно приобретёт вид представленный на рисунке 3.17. Выберите дату и смену, после чего нажмите кнопку «Вывести». Появится окно представленное на рисунке 3.18.

Рисунок 3.17 – Главная форма вкладка анализ

Рисунок 3.18 – Результаты анализа брака

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

Выводы по разделу

Выполнены следующие задачи:

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

2 Руководство пользователя включает назначение и условия выполнения АИС, выполнение АИС и сообщения пользователю.

Заключение

В данной дипломной работе была поставлена и решена задача автоматизации формирования отчётов, о проверенной листовой продукции, УЗК «Nukem» и «Nordinkraft» .

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

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

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

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

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

Методом нисходящего проектирования разработана реляционная база данных. Представлено техническое описание реляционных таблиц на языке описания данных.

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

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

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

Руководство программиста содержит рисунки, поясняющие процесс настройки.

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

Список использованных источников

Сайт «Металлоинвест». [Электронный ресурс] – Режим доступа: http://metalloinvest.com/
Сайт «Nukem». [Электронный ресурс] – Режим доступа: http://www.nukem.de
Сайт «NordinKraft». [Электронный ресурс] – Режим доступа: http://www.nordinkraft.com
Сайт «Active XL Report». [Электронный ресурс] – Режим доступа: http://www.afalinasoft.com/rus/active-xl-report
Сайт «SharpShooter Reports». [Электронный ресурс] – Режим доступа: http://www.perpetuumsoft.com/Report-Sharp-Shooter.aspx
Методические указания к лабораторным работам по курсу «САПР» [Электронный ресурс] / Н. А. Соловьёв. [Электронный ресурс] – Режим доступа: //unpk.osu.ru/povtas
Сайт «Microsoft». [Электронный ресурс] – Режим доступа: http://www.microsoft.com
Сайт «InterBase». [Электронный ресурс] – Режим доступа: http://www.ibase.ru
Сайт «Oracle». [Электронный ресурс] – Режим доступа: http://www.oracle.com
Сайт «Borland». [Электронный ресурс] – Режим доступа: http://www.borland.com
Волкова Т.В. Проектирование и создание БД: учебное пособие / Т.В. Волкова.
Гофман В.Э. Работа с базами данных в Delphi. – 2-е изд. – СПб.: БХВ-Петербург, 2003. – 624 с.: ил.
Баженова И.Ю. Delphi Самоучитель программиста. – М.: КУДИЦ-ОБРАЗ, 2002. – 432 с.: ил.
Зубкова Т.М. Технология разработки программного обеспечения: Учебное пособие.
Полякова Л.Н. Основы SQL. Учебное пособие. – М.: ИНТУИТ.РУ, Интернет-Университет Информационных Технологий, 2004. – 368 с.: ил.
А.В. Горячев. Microsoft Visual Studio 2005. [Электронный ресурс] – Режим доступа: WWW.URL: http://www.ci.ru/ inform21_05/phtm
Петров В.Н. Информационные системы. – СПб.: Питер, 2002. – 688 с.
Полякова Л.Н. Основы SQL. Учебное пособие. – М.: ИНТУИТ.РУ, Интернет-Университет Информационных Технологий, 2004. – 368 с.: ил.
Боронин С. Благородные диалекты SQL, 2002, №3, С. 41-42
ВСЁ о MS SQL [Электронный ресурс] – Режим доступа: http://www.xserver.ru/computer/database/mysql/10/
Борзов Ю.В. Методы тестирования и отладки программ ЭВМ. Рига, ЛГУ им. П. Стучки, 1980.
ГОСТ 19.102-77. Стадии разработки ПО.
ГОСТ 19.101-77. Виды программных документов.
ГОСТ 19.402-78. Описание программы.
ГОСТ 19.701-90 ЕСПД. Схема алгоритмов, программ, данных и систем.
ГОСТ 19.301-79. Программа и методика испытаний.
ГОСТ 19.503-79. Руководство системному программисту.
ГОСТ 19.505-79. Руководство оператору.
ГОСТ 19.701-90. Схемы алгоритмов, программ, данных и систем.
Введ.1.01.92.-М.:Издательство стандартов,1990.-25с.

Приложение А

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

SQL – запросы

if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[FK_GOSTNuk_BlecheNuk1]') and OBJECTPROPERTY(id, N'IsForeignKey') = 1)

ALTER TABLE [dbo].[GOSTNuk] DROP CONSTRAINT FK_GOSTNuk_BlecheNuk1

GO

if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[FK_BlecheNK_BrigadeNK]') and OBJECTPROPERTY(id, N'IsForeignKey') = 1)

ALTER TABLE [

Приложение Б

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

Листинг программы

program Project1;

uses

Forms,

Unit1 ++

{$R *.res}

(ЧАСТЬ ЛИСТИНГА НЕ ДОСТУПНА ДЛЯ ПУБЛИЧНОГО ПРОСМОТРА)

Скачать:d.rar

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

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

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

Наверх

1	2	3	4	5	6	7	8	9	10
8		R
9			I
10			U
11			D
12			R
13				I
14				U
15				D
16				R
17					I
18					U
19					D
20					R
21						I
22						U
23						D
24						R
25							I
26							U
27							D
28							R
29								I
30								U
31								D
32								R
33									I
34									U
35									D
36									R

1	2	3	4	5	6	7	8	9	10
8		R
9			I
10			U
11			D
12			R
13				I
14				U
15				D
16				R
17					I
18					U
19					D
20					R
21						I
22						U
23						D
24						R
25							I
26							U
27							D
28							R
29								I
30								U
31								D
32								R
33									I
34									U
35									D
36									R

1	2	3	4	5	6	7	8	9	10
8		R
9			I
10			U
11			D
12			R
13				I
14				U
15				D
16				R
17					I
18					U
19					D
20					R
21						I
22						U
23						D
24						R
25							I
26							U
27							D
28							R
29								I
30								U
31								D
32								R
33									I
34									U
35									D
36									R