Разработка АИС учета деятельности спортивного комплекса «Резерв»

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

 

2. ПРОЕКТ АВТОМАТИЗИРОВАННОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ учета деятельности спортивного комплекса «Резерв»

1. Функциональное обеспечение

В БМАУ спортивно-оздоровительного комплекса "Резерв" регулярно проводятся различные соревнования. Для участия в соревнованиях обязательно своевременно должна быть подана заявка. На основании заявки составляется таблица участников соревновании. Эта таблица по мере протекания соревнований заполняется.

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

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

Рассмотрим подробнее работу в спортивном комплекса "Резерв", технологии организации и управления проведением спортивных соревнований на основе методологии функционального моделирования. В ходе проведенного обследования деятельности предприятия была разработана структурно-функциональная диаграмма IDЕF0.

IDEF0 — FunctionModeling — методология  функционального моделирования  и графическая нотация, предназначенная  для формализации и описания  бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость  объектов. В IDEF0 рассматривается логические  отношения между работами, а не  их временная последовательность.

Каждая IDEF0-диаграмма содержит блоки и дуги. Блоки изображают функции моделируемой системы. Дуги связывают блоки вместе и отображают взаимодействия и взаимосвязи между ними. Функциональные блоки (работы) на диаграммах изображаются прямоугольниками, означающими поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Имя работы должно быть выражено отглагольным существительным, обозначающим действие. [9]

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

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

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

Стрелки управления - это правила стратегии, процедуры или стандарты.

Стрелки выхода - это данные, материальные объекты, что производятся работой.

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

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

 

Рисунок 3 – Контекстная диаграмма «to-be»

 

Рисунок 4 – Контекстная диаграмма «Деятельность спортивного комплекса»

 

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

 

Рисунок 5 – Декомпозиция процесса «Создание заявки на участие»

 

При подготовке соревнований, на основании заявки на участие происходит формирование команд. Затем формируется тренерский состав – данные вносятся в программу администратором или берутся из БД тренеров. Также, формируется судейский состав, сведения берутся из БД судей или вносятся вручную. В итоге, на основании списков команд, тренеров и судей формируется положение о соревнованиях, что видно на рисунке 6.

 

Рисунок 6 – Декомпозиция процесса «Подготовка соревнований»

 

Затраты на проведение соревнований рассчитываются на основании положения о соревнованиях и статей затрат, формируется отчет о затратах на соревнования в соответствии с рисунком 7.

 

Рисунок 7 – Декомпозиция процесса «Учет затрат на соревнования»

2. Информационное обеспечение

Для разработки данного проекта применялись элементы объектно-ориентированного программирования в BPwin.

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

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

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

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

В проектируемой модели использовалась логико-физическая модель. [11]

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

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

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

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

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

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

В результате анализа (раздел 1) были выделены категории концептуальных классов, представленные в таблице 2. 1.

Таблица2. 1 – Список категорий концептуальных классов

Категория концептуальных классов	Примеры
Физические и материальные объекты	Пользователи Документы
Роли людей	Администратор Организатор соревнований
События	Создание заявок на участие Редактирование заявок на участие Просмотр личной карточки участника Удаление личной карточки участника Создание информации о командах Составление информации о тренерском составе Составление информации о судейском составе Просмотр вида спорта
Процессы	Авторизация Работа с заявками участников Работа с информацией о командах Работа с информацией о тренерском составе Работа с информаций о судейском составе

 

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

«Заявка участника» - содержит информацию об участнике.

«Команда» - содержит информацию о команде.

«Тренерский состав» - содержит информацию о тренерском составе.

«Результаты» - содержит информацию о результатах.

«Судейский состав» - содержит информацию о судейском составе. [12]

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

 

Таблица 2. 2 – Атрибуты классов для модели предметной области

Название класса	Атрибуты класса
Таблица «Заявка участника» содержит:	Код – уникальный код; ФИО – фамилия, имя, отчество игрока; дата рождения; Пол; Вес; Название группы (команды).
Таблица «Командный состав» содержит:	Код – уникальный код ; Название команды – название команды; Возраст – возраст игрока; Зарплата – зарплата игрока; ФИО – фамилия, имя, отчество игрока; Место рождение – место рождение игрока; Дата образования – дата образование команды; Рейтинг-команды – рейтинг команды. Позиция – позиция игрока.
Таблица «Судейский состав» содержит:	Код – уникальный код; ФИО - фамилия, имя, отчество судьи; Возраст – возраст судьи; Зарплата – зарплата судьи; Качество судейства – качество судейства судьи.
Таблица «Тренерский состав» содержит:	Код – уникальный код ; ФИО - фамилия, имя, отчество игрока; Команда – название команды; Возраст – возраст тренера; Зарплата – зарплата тренера; Место рождение – место рождение тренера.
Таблица «Результаты» содержит:	Код – уникальный код ; Счет – счет матча; Судья матча – судья матча; Команда1 – команда первая; Команда2 – команда вторая; Дата и время проведения – дата и время проведения соревнований. Погода – погода Название стадиона – название стадиона, где проходит матч.