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

ОБРАЗОВАТЕЛЬНАЯ ОРГАНИЗАЦИЯ ВЫСШЕГО ОБРАЗОВАНИЯ (АССОЦИАЦИЯ)

«КИСЛОВОДСКИЙ ГУМАНИТАРНО-ТЕХНИЧЕСКИЙ ИНСТИТУТ»

Факультет Инженерный

Кафедра Систем автоматического управления

Направление Управление в технических системах

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА к выпускной квалификационной работе на тему:

РАЗРАБОТКА БАЗЫ ДАННЫХ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ ПОВЕРКИ ПРИБОРОВ УЧЁТА ЭЛЕКТРОЭНЕРГИИ.

Студент: Костин А.А. гр. 241

Кисловодск

2017

Реферат

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

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

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

Введение

Выпускная квалификационная работа посвящена автоматизации поверки электросчётчиков на примере Федерального бюджетного учреждения «Государственный региональный центр стандартизации метрологии и испытаний в г. Пятигорск», в дальнейшем сокращенно ФБУ«Пятигорский ЦСМ».

ФБУ«Пятигорский ЦСМ»является федеральным центром по поверке электросчётчиков. Автоматизации учета приборов в нем определена большим числом поверок электросчётчиков и большим числом контролёров, для более удобного поиска электросчётчиков нуждающихся в поверке и своевременного предупреждения о ней, а также для более удобного создания отчетности.

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

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

Цель работы определила следующие задачи:

- выявление связей и сущностей,

- установление структуры предприятия,

- исследование всей документацииучреждения,

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

- анализ услуг, существующих вучреждение,

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

- расчёт экономической эффективности разработки,

- оценка экологичности и безопасности для окружающих.

1. Характеристика предприятия

ФБУ «Пятигорский ЦСМ» является современным, развивающимся учреждение, основанный в городе Пятигорске в 1935 году, которая ведет свою работу в области метрологии и стандартизации, осуществляет: поверку приборов, выпускаемых на производстве, поверку приборов, выпускаемых из ремонта, поверку приборов, находящихся в обращении и поверку образцовых приборов предприятий; контрольно-ревизионная работа.

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

К основным услугам, предоставляемым организацией, относятся:

- Поверка электросчётчиков и поверяющей техники.

- Контроль за электросчётчиками и поверяющей техникой.

- Выдача сертификата и наклейки поверки.

- Выезд контролёра на дом.

Клиенты ФБУ «Пятигорский ЦСМ» имеют возможность вызвать контролёра на место установки электросчётчика, путем подачи заявки через диспетчерскую службу сервисном центре, а также привезти поверяющую технику в лабораторию самостоятельно. Также проходят плановые проверки электросчётчиков в цели профилактики приборов.

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

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

ФБУ «Пятигорский ЦСМ» работает в Пятигорске и имеет один филиал в Ессентуках. Поэтому её организационная структура проста.

Организационная структура ФБУ «Пятигорский ЦСМ» представлена на рисунке 1.

Рисунок 1.1- Организационная структура учреждения

К задачам и обязательствам Отделов ФБУ «Пятигорский ЦСМ» относятся:

- Прием и регистрация заявок на поверку;

- Консультация клиентов по телефону и электронной почте;

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

- Контроль и координация с работой контролёров;

- Выдача сертификата о поверке;

- Своевременно сообщать о неполадках IT-отделу;

- Предоставление отчетности о выполненных работах.

К функциям и задачам IT-отдела относятся:

- Консультация по полученным заявкам;

- Устранения неполадок;

- Обеспечение стабильной работы учреждения и филиала;

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

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

- Выезд в филиал для работ.

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

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

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

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

- Контроль за работой своего учреждения.

- Взаимодействие с государственными налоговыми и иными органами.

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

1.2 Программное обеспечение, используемое предприятием

На предприятии используются все средства Microsoft, распространена операционная система WindowsServer 2016 EnterpriseEdition.

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

Почтовые программы:

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

OutlookExpress является системной программой Windows, начиная с Windows 95 OSR 2.5 и Windows NT.

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

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

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

Задача автоматизации поверки электросчётчиков актуальна в связи с большой номенклатурой и большим количеством поверяемого оборудования в лаборатории ФБУ «Пятигорский ЦСМ».

2. Проектирование автоматизированной информационной системы

2.1 Описание предметной области

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

Информационная система будет эксплуатироваться в ФБУ «Пятигорский ЦСМ», который занимается поверкой электроприборов и выдача сертификатов.

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

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

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

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

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

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

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

* SADT (StructuredAnalysisandDesignTechnique) модели и соответствующие функциональные диаграммы;

* DFD (DataFlowDiagrams) диаграммы потоков данных;

* ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".

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

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

Методология функционального проектированияSADT разработана Дугласом Россом. На ее основе разработана методология IDEF0 (IcamDEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США.

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

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

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

* ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);

* связность диаграмм (номера блоков);

* уникальность меток и наименований (отсутствие повторяющихся имен);

* синтаксические правила для графики (блоков и дуг);

* разделение входов и управлений (правило определения роли данных).

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

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

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

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

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

* уменьшение сложности программного обеспечения;

* повышение надежности программного обеспечения;

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

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

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

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

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

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

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

UML основывается на технологии объектно-ориентированного програмирования. Объединяет в себе всю мощь объектно-ориентированного подхода и дает четкую модель системы, отражающую все ее значимые стороны. К середине девяностых явными лидерами в этой области стали методы Booch (GradyBooch), OMT-2 (JimRumbaugh), OOSE -- Object-Oriented SoftwareEngineering (IvarJacobson). Однако эти три метода имели свои сильные и слабые стороны: OOSE был лучшим на стадии анализа проблемной области и анализа требований к системе, OMT-2 был наиболее предпочтителен на стадиях анализа и разработки информационных систем, Booch лучше всего подходил для стадий дизайна и разработки.

Создание UML началось в октябре 1994 г., когда Джим Рамбо и Гради Буч из Rational Software Corporation стали работать над объединением своих методов OMT и Booch. Осенью 1995 г. увидела свет первая черновая версия объединенной методологии, которую они назвали Unified Method 0.8. После присоединения в конце 1995 г. к Rational Software CorporationАйвара Якобсона и его фирмы Objectory, усилия трех создателей наиболее распространенных объектно-ориентированных методологий были объединены и направлены на создание UML.

UML представляет собой объектно-ориентированный язык моделирования, обладающий следующими основными характеристиками:

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

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

UML -- это стандартная нотация визуального моделирования программных систем, принятая консорциумом ObjectManaging Group (OMG) осенью 1997 г., и на сегодняшний день она поддерживается многими объектно-ориентированными CASE-продуктами.

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

Пользователям языка предоставлены возможности:

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

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

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

2.2.1 Этапы проектирования ИС с применением UML

UML обеспечивает поддержку всех этапов жизненного цикла ИС и предоставляет для этих целей ряд графических средств - диаграмм.

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

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

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

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

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

Диаграммы видов деятельности (диаграммы деятельностей, activitydiagrams) - модель бизнес-процесса или поведения системы в рамках прецедента.

Диаграммы взаимодействия (interaction diagrams) - модель процесса обмена сообщениями между объектами, представляется в виде диаграмм последовательностей (sequencediagrams) или кооперативных диаграмм (collaboration diagrams).

Диаграммы состояний (statechartdiagrams) - модель динамического поведения системы и ее компонентов при переходе из одного состояния в другое.

Диаграммы классов (classdiagrams) - логическая модель базовой структуры системы, отражает статическую структуру системы и связи между ее элементами.

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

Диаграммы компонентов (component diagrams) - модель иерархии подсистем, отражает физическое размещение баз данных, приложений и интерфейсов ИС.

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

На рисунок 2.1 показаны отношения между различными видами диаграмм UML. Указатели стрелок можно интерпретировать как отношение "является источником входных данных для..." (например, диаграмма прецедентов является источником данных для диаграмм видов деятельности и последовательности). Приведенная схема является наглядной иллюстрацией итеративного характера разработки моделей с использованием UML.

Рисунок 2.1 Взаимосвязи между диаграммами UML

Ниже приводятся описания последовательных этапов проектирования ИС с использованием UML.

2.2.2 Использование основных объектов UML в проектирование информационной системы ФБУ «Пятигорский ЦСМ»

Классы

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

В рамках модели каждому классу присваивается уникальное имя - в нашем проекте это Учетная запись.

Атрибут -- это свойство класса, которое может принимать множество значений. Множество допустимых значений атрибута образует домен. Атрибут имеет имя и отражает некоторое свойство моделируемой сущности, общее для всех объектов данного класса. Класс может иметь произвольное количество атрибутов. Например, для класса объектов Учетная запись информационной системы ФБУ «Пятигорский ЦСМ» определены атрибуты ID - уникальный идентификатор пользователя, Логин, Должность, Пароль.

Операция -- реализация функции, которую можно запросить у любого объекта класса. Операция показывает, что можно сделать с объектом. Исполнение операции часто связано с обработкой и изменением значений атрибутов объекта, а также изменением состояния объекта. Для класса объектов Учетная запись информационной системы ФБУ «Пятигорский ЦСМ» определена операция Регистрация.

На рисунке 2.2 приведено графическое изображение класса "Учетная запись" в нотации UML.



Рисунок. 2.2 Изображение класса в UML другое.

Синтаксис UML для свойств классов (в отдельных программных средствах, например, в IBM UML Modeler, порядок записи параметров может быть иным):

<признак видимости><имя атрибута> : <тип данных>

= <значение по умолчанию>

<признак видимости><имя операции><(список аргументов)>

Для класса объектов Учетная запись описание атрибута ID иметь следующий вид:

publicID: int = 0001

Для класса объектов Учетная запись описание операции Регистрация иметь следующий вид:

protected Регистрация: (int ID, string Логин, string* Должность, string Пароль)

Видимость свойства указывает на возможность его использования другими классами. Один класс может "видеть" другой, если тот находится в области действия первого и между ними существует явное или неявное отношение. Например, в данной информационной системы ФБУ «Пятигорский ЦСМ» атрибуты и операции доступны для класса объекта Поверка.

В языке UML определены три уровня видимости:

· public (общий) -- любой внешний класс, который "видит" данный, может пользоваться его общими свойствами. Обозначаются знаком " + " перед именем атрибута или операции, как в данном проекте для атрибута ID; Например, в объектеАдминистратороперацияУправление правами имеет общую видимость.

· protected (защищенный) -- только любой потомок данного класса может пользоваться его защищенными свойствами. Обозначаются знаком " # ", как в данном проекте для операции Регистрация; Например, в объекте Учетная запись операция Регистрация имеет защищенную видимость.

· private (закрытый) -- только данный класс может пользоваться этими свойствами. Обозначаются символом " - ". В данной системе нет операции с типом закрытый.

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

· instance (экземпляр) -- у каждого экземпляра класса есть собственное значение данного свойства;

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

В Базе Данных все классы имеют значение instance.

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

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

· не содержащие ни одного экземпляра -- тогда класс становится служебным ( Abstract );

· содержащие ровно один экземпляр ( Singleton );

· содержащие заданное число экземпляров;

· содержащие произвольное число экземпляров.

В Базе Данных все классы имеют ровно один экземпляр.

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

Диаграммы классов

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

Классы отображают типы объектов системы.

Между классами возможны различные отношения, представленные на рисунок 2.3:

· зависимости, которые описывают существующие между классами отношения использования;

· обобщения, связывающие обобщенные классы со специализированными;

· ассоциации, отражающие структурные отношения между объектами классов.



Рисунок 2.3 Отображение связей между классами

Зависимостью называется отношение использования, согласно которому изменение в спецификации одного элемента (например, класса " Контролер ") может повлиять на использующий его элемент ( класс " Учетная запись "). Часто зависимости показывают, что один класс использует другой в качестве аргумента.

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



Рисунок 2.4 - Отношение обобщения

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

Рисунок 2.5 Свойства ассоциации

Рисунок 2.5 иллюстрирует модель формирования заказа на поверку счетчика. Каждый заказ может быть создан единственным клиентом (множественность роли 1...1). Каждый клиент может создать один и более заказов (множественность роли 1..n). Направление навигации показывает, что каждый заказ должен быть " привязан " к определенному клиенту.

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

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

Диаграммы использования

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

· описывает видимую пользователем функцию,

· может представлять различные уровни детализации,

· обеспечивает достижение конкретной цели, важной для пользователя.

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

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

На рисунок 2.6 показано, что при исполнении прецедента " Прием на поверку " возможно использование информации из предыдущего заказа, что позволит не вводить все необходимые данные. А при исполнении прецедентов " Регистрация " необходимо выполнить одно и то же действие -- создать запись в таблицы "Поверяемое оборудование".

Рисунок 2.6 - Связи на диаграммах прецедентов

Динамические аспекты поведения системы отражаются приведенными ниже диаграммами.

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

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

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

Диаграммы последовательностей

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



Рисунок 2.7 - Диаграмма Выдача поверенных приборов

· вводятся строки выдачи с поверки;

· по каждой строке проверяется наличие поверки;

· если прибор поверен -- то он выдается с сертификатом о поверке, клиенту;

· если прибор не поверен -- инициируется поверка прибора.

Кооперативные диаграммы

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

Диаграммы состояний

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

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

Переходы имеют метки, которые синтаксически состоят из трех необязательных частей (см. рисунок 2.8):

Рисунок 2.8 Диаграмма состояний объекта «заказ»

<Событие><[Условие]>< / Действие>.

На диаграммах также отображаются функции, которые выполняются объектом в определенном состоянии. Синтаксис метки деятельности:

выполнить/< деятельность >.

Диаграммы деятельности

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

Основными элементами диаграмм деятельности являются (рисунок 2.9):

· овалы, изображающие действия объекта;

· линейки синхронизации, указывающие на необходимость завершить или начать несколько действий (модель логического условия "И");

· ромбы, отражающие принятие решений по выбору одного из маршрутов выполнения процесса (модель логического условия "ИЛИ");

· стрелки -- отражают последовательность действий, могут иметь метки условий.

Рисунок 2.9 - Диаграмма деятельности -- обработка заказа

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

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

Диаграммы компонентов

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

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

· устройства -- узлы системы, в которых данные не обрабатываются.

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

Для различных типов компонентов предусмотрены соответствующие стереотипы в языке UML.

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

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

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

Рисунок 2.10 Диаграмма компонентов фрагмента КИС

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

Пакеты UML

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

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

2.3 Диаграмма вариантов использования

Описание функционального назначения информационной системы ФБУ «Пятигорский ЦСМ» представим диаграммой вариантов использования UML. Диаграмма строится на основе анализа предметной области, является начальным концептуальным представлением системы в процессе её проектирования и разработки. В дальнейшем она детализируется в форме логических и физических моделей.

При построении диаграммы использования информационной системы ФБУ «Пятигорский ЦСМ» в качестве сущностей или актёров, используется пользователи системы: Администратор, Контролёр, Управляющий и Проверяющий. Вариантами использования являются: Регистрация и редактирование поверяющего оборудования; Внесение и редактирование данных о лицензиях и контролеров; Проверка деятельности контролера; Отчеты о поверяющих приборов и о поверки; Создание и выдача сертификатов; Регистрация и редактирование поверяемых приборов; Внесение данных о поверках; Отчеты о поверяемых приборов и о поверки; Создание и выдача наклеек и сертификатов; Просмотр данных в Базе Данных; Редактирование Базы Данных; Редактирование данных входа; Редактирование классов доступов в Базу Данных; Просмотр данных в отчетах; Просмотр Итоговой таблицы и Архива данных; Просмотр методов регистрации и редактирования Базы Данных.

Для Администратора системы определены следующие варианты использования: Просмотр данных в Базе Данных; Редактирование Базы Данных; Редактирование данных входа; Редактирование классов доступов в Базу Данных.

Для Проверяющего определены следующие варианты использования: Просмотр данных в Базе Данных; Просмотр данных в отчетах; Просмотр Итоговой таблицы и Архива данных; Просмотр методов регистрации и редактирования Базы Данных.

Для Проверяющего определены следующие варианты использования: Регистрация и редактирование поверяющего оборудования; Внесение и редактирование данных о лицензиях и контролеров; Проверка деятельности контролера; Отчеты о поверяющих приборов и о поверки; Создание и выдача сертификатов.

Для Проверяющего определены следующие варианты использования: Регистрация и редактирование поверяемых приборов; Внесение данных о поверках; Отчеты о поверяемых приборов и о поверки; Создание и выдача наклеек и сертификатов.

Как видно из диаграммы использования вариант использования Просмотр данных в Базе Данных является общим для актёров Администратор и Проверяющий.

Рисунок2.11 - Диаграмма вариантов использования

Диаграмма использования в данной работе определит интерфейс информационной системы ФБУ «Пятигорский ЦСМ», а именно, состав форм для ввода информации о поверяемых приборов, регистрации новых пользователей, формирование запросов на отчёты системы.

2.4 Диаграмма Сущность-связь

Диаграмма "сущность-связь" (ERD) нацелена на определения отношений между моделями данных и их типов.

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

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

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

Все пользователи подтверждают свою личность в системе, путем ввода индивидуального логина и пароля.

Администратор осуществляет Редактирование классов доступов в Базу Данных и редактирование данных входа в неё.

Проверяющий осуществляет проверку деятельности Контролера и Управляющего.

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

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

Рисунок 2.12 - Диаграмма сущность-связь

2.5 Диаграмма развертывания

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

Диаграмма развертывания предназначена для отображения компонентов и элементов программы, имеющихся в Базе Данных. На этой диаграмме отображаются все компоненты, входящие в информационную систему ФБУ «Пятигорский ЦСМ».

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

Узлами-экземплярами в системе учета выработки являются автоматизированное рабочее место Администратора, автоматизированное рабочее место Управляющего, с имеющимся на нем компонентом Client.exe; сервер базы данных с имеющимся на нем компонентами Server.exe и Поверка.db. В составПоверка.db входя такие компоненты как: Вход, Поверка, Лицензия, Контролер, Поверенные приборы, Поверяющие приборы, Операции поверки, Параметры Измерения, расположенные на сервере.

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

Для связи с Поверяющими и Контролерами используется интернет(Internet, TCP\IP, Wi-Fi) для того, что эти пользователи имели доступ к информационной системе ФБУ «Пятигорский ЦСМ» в любой точке мира. А также это сделано для того, что Проверяющий мог в любой момент войти в базу данных и проверить деятельность учреждения.

Рисунок 2.13 - Диаграмма развертывания

2.6 Диаграмма компонентов

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

Server.exe и Client.exe-это компоненты являющиеся исполнимыми модулями.

Поверка.drp и Server.drp, Поверка.db - компоненты-рабочие продукты.

Администратор, Контролер, Управляющий, Поверяющий,тКонтролер, Запрос за текущий год, Запрос за текущий месяц, Запрос на Итоговую таблицу, Запрос на количества использования прибора, Запрос не используемых приборов, Многотабличный Запрос,Неповерятые счетчики, Запрос* на Даты поверок,Запрос на таблицу Даты поверок, СЗапрос на вид поверки, ТЛицензия, Обновление дат, Удаление счетчиков, Карточка счетчика,Форма Архив,Подчиненная форма Карточки контролера, Карточка контролера, Форма Регистрации новой поверки, Форма Регистрации нового счетчика,тОперацииПоверки, Главная кнопочная форма Контролёра, Главная кнопочная форма Управляющего, Главная кнопочная форма Проверяющего, Карточки Поверяющего Оборудования,Наклейки Поверки, Отчет за текущий год, Отчет за текущий месяц, Отчет о Поверки,Отчет Поверяющее Оборудование,тПараметрыИзмерения, Отчет Сертификата, Форма Вход, Форма Регистрации,тПоверка,тПоверяемоеОборудование,тПоверяющееОборудование,тВход- компоненты развертывания, которые обеспечивают непосредственное выполнение системой своих функций.

Компоненты связаны отношением зависимости.



Рисунок 2.14 - Диаграмма компонентов для клиентской части

Рисунок 2.15 - Диаграмма компонентов для серверной части

2.7 Диаграмма активности

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

Рисунок 2.16 - Диаграмма активности для оформления прихода

При действии «Прием на поверку» наблюдается Электросчетчики.

Рисунок 2.17 - Диаграмма активности для оформления расхода

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

Рисунок 2.18 - Диаграмма активности для Поверяющего

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

Рисунок 2.19 - Диаграмма активности для Контролера

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

Рисунок 2.20 - Диаграмма активности для Управляющего

Для Управляющего после авторизации с помощью пароля наблюдается разделение деятельности на Открытие Поверяющего оборудования, Ведение Контролер, Открытие справочника Поверка, Ведение справочника Лицензии, а также выполнения запросов, отчетов.

Рисунок 2.21 - Диаграмма активности для администратора

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

2.8 Диаграмма классов

Рисунок 2.22 - Диаграмма классов

На диаграмме представлены классы Проверяющий, Администратор, Управляющий, Контролер, Лицензия, Поверяемое Оборудование, Поверяющее Оборудование, Поверка, тКонтролер, Операции Поверки, Параметр Измерения, Учетная запись. В каждом классе указаны его значения, а также действия, возможные для данного класса.

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

Все остальные классы связаны отношением композиция.

автоматизированный информационный электросчётчик запрос

3. Разработка автоматизированной информационной системы

3.1 Основные сведенья о информационной системе

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

К компонентам информационной системы относится:

· База данных

· Концептуальная схема

· Информационный процессор, образующие вместе систему хранения и манипулирования данными

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

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

· Сокращение избыточности хранимых данных благодаря однократному хранению каждого сообщения в базе данных;

· Совместное использование хранимых данных всеми пользователями ИС;

· Стандартизацию представления данных, упрощающую проблемы эксплуатации БД и обмена данными между ИС;