3.1. Описание программного инструмента Dbforge DbForge Studio for MySQL — универсальное решение для разработки, администрирования и управления базами данных MySQL.


Чтобы посмотреть этот PDF файл с форматированием и разметкой, скачайте его и откройте на своем компьютере.
«Санкт
-
Петербургский государственный электротехнический университет

«ЛЭТИ» им. В.И.Ульянова (Ленина)»

(СПбГЭТУ “ЛЭТИ”)


Специальность

230102.65
-

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

Специализация


Факультет

ОФ

Кафедра

АСОИУ

К
защите допустить


Зав. кафедрой


Цехановский В.В.



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

СПЕЦИАЛИСТА


Тема:
Разработка информационной системы для поддержки
деятельности детской студии



Студент
ка




Печникова Е.В.



подпись



Руководитель

к.т.н., доцент
каф.
АСОИУ



Дубенецкий В.А.



подпись



Консультанты

д.э.н., профессор
каф. ПЭ



Веретенников Н.П.



подпись







Санкт
-
Петербург

2016

2


ЗАДАНИЕ

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



Утверждаю


Зав. кафедрой
АСОИУ


____________
Цехано
в
ский В.В.


«___»______________20
__
_ г.


Студентка

Печникова Е.В.


Группа

0851

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

Место выполнения ВКР:
Санкт
-
Петербургский государственный
электротехнический университет «ЛЭТИ»
им. В.И.Ульянова (Ленина)
.

Исходные данные (технические требования):

Система должна обеспечить

ведение данных

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

от
четов

о доходности
, выводить статистические данные
востребованности занятий.

Содержание ВКР:

Анализ деятельности детской студии,
сценарий,
разработка проекта ИС,
реализация фрагментов ИС.

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

Дополнительные разделы:
ТЭО
.


Дата
выдачи задания

Дата представления ВКР к защите

«___»______________20
__
_ г.

«___»______________20
__
_ г.




Студент
ка


Печникова Е.В.

Руководитель

к.т.н., доцент каф.

АСОИУ


Дубенецкий В.А.

3


КАЛЕНДАРНЫЙ ПЛАН

ВЫПОЛНЕНИЯ

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



Утверждаю


Зав. кафедрой
АСОИУ


____________
Цехановский В.В.


«___»______________20
__
_ г.


Студентка

Печникова Е.В
.


Группа

0851

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



п/п

Наименование работ

Срок
выполнения

1

Обзор литературы по теме работы

20.02


08.03

2

Анализ деятельности детской студии

09.03


25.03

3

Разработка проекта ИС

26.03


23.04

4

Реализация фрагментов ИС

24.04


10.05

5

Оформление пояснительной записки

11.05


24.05

6

Оформление иллюстративного материала

25.05


04.06



Студент
ка


Печникова Е.В.

Руководитель

к.т.н., доцент
каф. АСОИУ


Дубенецкий В.А
.


4


РЕФЕРАТ

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

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

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

StarUML
.


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

Visio
.

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

Studio

for

SQL
.

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

В

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

В

отчёте содержится: страниц


108
, иллюстраций


45, таблиц


9,
диаграмм


18, частей



4, источников


14
.

ИНФОРМАЦИОННАЯ СИСТЕМА, БАЗА
ДАННЫХ, СЕ
МАНТИЧЕСКОЕ

МОДЕЛИРОВАНИЕ, ПРОЕКТИРОВАНИЕ

СИСТЕМЫ

5


ABSTRACT


The aim of this work is to develop an information system to support the
children's studio work. In this work a detailed analysis of the subject area, describe
development. The final result is an
information system developed by the database on which to base possible software
implementation product.

Keywords:
information system, database,

semantic modeling, system design
.








































6



СОДЕРЖАНИЕ



Сокращения

Введение

8

9

1

Анализ деятельности детской студии

13

1.1.

Основные цели и задачи деятельности детской студии

13

1.2.

Штатная
структура детской

студии


14

1.3.

1.4.

1.5.

1.6

1.7

1.8

Целевая аудитория детской студии

Документация детской студии

Описание программного инструмента
StarUML

Сценарий

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

Модель этапа анализа

22

23

2
5

27

33


39


2

Разработка проекта ИС

48

2.1.

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

48

2.2.

Разработка моделей классов

57

2.3.

2.4

2.5

Microsoft

Visio

ER
-
диаграмма

Построение

ER
-
диаграмм

65

66

67

3

Реализация фрагментов ИС

73

3.1.

Описание программного инструмента
Dbforge

73

3.2.

Разработка базовых структур и типовых запросов

73

4

Технико
-
экономическое обоснование

94

4.1.

Обоснование целесообразности разработки проекта

94

4.2.

Планирование комплекса работ по разработке темы и оценка
трудоемкости

95

4.3.

4.4.


Расчет затрат на сырье и материалы

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

99

101


7


4.5.

4.6.

4.7.

4.8.

Расчет затрат на амортизационные отчисления

Расчет накладных расходов

Расчет общей величины затрат

Вывод

102

102

103

104


Заключение

106


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

108






































8



СОКРАЩЕНИЯ


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

БД


база данных

д/с
-

детская студия

ЕСН


единый социальный налог

СУБД


система управления базами данных

ИС


информационная система

РФ



Российская Федерация

ФИО


фамилия, имя, отчество

ФКЦБ


Федеральная комиссия по рынку ценных бумаг

CASE
-

c
omp
uter
-
aided software engineering

ER


entity
-
relationship

SQL


structured query language

UML


Unified Modeling Language





















9


ВВЕДЕНИЕ


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

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

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

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

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

10


Преимущество автоматизации


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

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

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


Цель данной ра
боты


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

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

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

Модель


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


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


Диаграмма
-

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

11



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

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

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



сущность,
Relation



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

Существуют различные варианты отображения
ERD
, но все варианты
диаграмм «сущность
-
связь» исходят из одной
цели


рисунок всегда
нагляднее текстового описания.
ER
-

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

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

Studio

for

SQL

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

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

1.

Обследовать объект автоматизации;

2.

Подготовить техническое задание на разработку информационной
системы

3.

Произвести анализ разрабатываемой информационной системы;

4.

Про
извести детальное проектирование автоматизированной
системы;

12


5.

Разработать модель данных;

6.

Организовать обработку данных.


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



































13


1.
АНАЛИЗ ДЕЯТЕЛЬНОСТИ
ДЕТСКОЙ СТУДИИ


1.1.
Основные цели и задачи деятельности
детской студии

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

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

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


творческое, интеллектуальное, культурное, физическое,
речевое, соц
иально
-
коммутативное, познавательное и т.д.

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

Структура детского объединения включает в себя учебные группы,
количество к
оторых определяется спросом со стороны детей и родителей.
Деятельность детей осуществляется в одновозрастных детских объединениях
по интересам (учебные группы и факультативные группы). Группы
формируются в соответствии с возрастом по 8
-
12 детей в группе.

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


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

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

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

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

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


1.
2
.
Штатная структура детской студии

Главным организатором, контроллером и координатором деятельности
детской студии является директор, в дальнейшем именуемый, как
Работодатель. Учитывая все нюансы, работодатель должен создать
15


максимально комфортные условия для детей, их родителей, а также
со
трудников студии.

Работодатель
-

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

Сотрудник



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


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


Соблюдать правила внутреннего трудового распорядка;


Соблюдать

трудовую дисциплину;


Выполнять установленные нормы труда;


Соблюдать требования по охране труда и обеспечению
безопа
сности труда;


Бережно относиться к имуществу работодателя (в том числе к
имуществу третьих лиц, находящемся у работодателя, если
работодатель несет ответственность за сохранность этого имущества) и
других работников;


Незамедлительно сообщать работодателю л
ибо
непосредственному руководителю о возникновении ситуации,
представляющей угрозу жизни и здоровью людей, сохранности
имущества работодателя (собрание законодательства РФ);

16



Проходить обязательные предварительные (при поступлении на
работу) и периодические

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

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


Замечание;


Выговор;


Увольнение по соответствующим основаниям.

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

В данной системе сотрудники могут работать по сл
едующим
специальностям (профессиям):


Генеральный директор;


Преподаватель;


Администратор;


Менеджер по продажам;


Бухгалтер;


Уборщик.

Администратор



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


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



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



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



Распечатка документов;



Обработка заявок от клиентов;



Взаимодействие с педагогами (помощь в подготовке к занятиям);



Работа с кассовым аппаратом, выписка квитанций;



Консультирование посетителей;



Контроль поступления платежей;



Прием входящих звонков, отправление смс
-
рассылок о занятиях;



Обеспечение
наличия всех необходимых
пособий и материалов для
студии (закупка и доставка);



Помощь в организации мероприятий.

Администратор
несет ответственность за ненадлежащее или неисполнение

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

Преподаватель
-

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

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



Осуществлять дополнительное обучение и развитие детей;



Комплектов
ать состав обучающихся групп;

18




Участвовать
в разработке и реализации образовательных
программ;



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



Вести документацию и отчетность;



Выявлять способности обучающихся и способствовать их
развитию, проводить тестирование;



Орга
низовать
участие обучающихся в массовых
мероприятиях;



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



Участвовать в оформлении помещений студии;



Посещение

педагогических внутристудийных

собраний;



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

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

Уборщик

-

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


Осуществление уборки служебных помещений;


Чистка и дезинфекция санитарно
-
технического оборудования;


Приготовление моющих и дезинфицирующих растворов;


Слежение за наличием моющих средств и приспособлений.

19


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

Менеджер по продажам

-

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


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


Работа с денежными ср
едствами, сбор отчетности по рабочим
затратам;


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


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


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

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

Бухгалтер

-

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

20



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


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


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


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


Произведение начислений и перечислений

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

а
также отчисление средств на материальное стимулирование
работников студии;


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


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


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


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


Принятие мер по накоплению финансовых средств для
обеспечения финансовой устойчивости предп
риятия;


Участие в оформлении материалов по недостачам и хищениям
денежных средств и товарно
-
материальных ценностей.

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


Генеральный директор



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


Организация, координация и контроль деятельности компании;


Стратегическое планирование развитие компании и реализация
этих планов;


Повышение конкурентоспособности компании;


Осуществление подбора, найма и увольнения сотрудников;


Развитие професс
иональных знаний и опыта сотрудников;


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


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


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

22



Повышение качества оказываемых услуг;


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


Обеспечение соблюдения законности в деятельности студии;


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

1.3.

Целевая аудитория детской студии

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

Ребенок

-

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

Родитель

или лицо, заменяющее его
-

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


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

Потенциальный

клиент



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


1.4.
Документация детской студии

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

К основным документам детской студии можно отнести:



Карточка ребенка;



Журнал посещаемости;



Табельное расписание;



Расписание проведений занятий;



Книга учета денежных средств;

24




План мероприятий;



План заня
тий;



Списки учащихся групп;



Бланк необходимых закупок;



Информационная книга.

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

Журнал посеща
емости предназначен для системы учета посещаемости
учащихся.

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

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

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

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

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

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

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

В информационную книгу заносятся адреса, телефоны, ФИО
контактных лиц и другая информация о поста
вщиках, магазинах, местах
25


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


1.5.
Описание программного инструмента
StarUML


StarUML
-

программный инструмент моделирования, который
поддерживает UML (Унифицированный язык моделирования). StarUML
ориентирован
на UML версии 1.4 и позволяет разработать

одиннадцать
различных типов диаграмм, принятых в нотации UML 2.0. Он активно
по
ддерживает подход MDA (Модельно
-
управляемая архитектура), реализуя
концепцию профилей UML. Среда разработки StarUML ™ превосходно
настраивается

исходя из требований
пользователя
,

и имеет

весьма

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


UML
-

это язык визуального моделирования систем. Моделирование
систем с помощью UML предполагает построение ряда взаимосвязанных
диаграмм. Для сопровождения процесса построения, анализа и
документирования модели, а также проверки модели и генер
ации
программных кодов разработчики используют специально для этих целей
созданные CASE
-
инструменты проектирования систем. В общем смысле
CASE (Computer
-
Aided Software Engineering)


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

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

с помощью UML). В данной
дипломной работе для моделирования системы выбран программный
ин
струмент моделирования StarUML.
Данная программная платформа имеет
26


свободную лицензию и доступна для установки с официального
вэб
-
сайта
StarUML.


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

в модель только

аспекты прое
ктируемой системы
имеющие

непосредственное отношение к выполнению с
истемой своих
функций или

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

не усложнять

сверх меры

процесс анализа и исследования
полученной модели.


Основная структурная единица

в StarUML


это проект. Пр
оект
сохраняется в одном файле формата

XML с расширение
м «.UML». Проект
может включать в себя

одну и
ли несколько моделей и разнообразные

представления этих моделей (View)


визуальные выражения информации,
содержащейся в моделях.

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


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

В отличие от множества

существующих

ныне

программ,
в которых

используют
ся

собственные неэффективные форматы файла модели, StarUML
оперирует файл
ами в стандартном формате XML. Коды
, написанные в легко
читаемых

структу
рах и форматах, могут быть свободно

изменены с помощью
синтаксич
еского анализатора XML. Принимая во внимание тот

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


27


1.6.
Сценарий

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

способ
ов

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


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

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


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


Д
еятельности могут иметь предусловия и постусловия, как и
прецеденты. Предусловия


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


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


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


Рисунок 1
.
1
-

Начальный узел


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


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


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

Каждый раздел деятельности


это группа взаимосвязанных
действий с высоким уровнем вложенности. Иногда разделы деятельности
называют плавательными дорожкам
и (
swimlanes
). Разбиение на разделы


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


Рисунок 1.2


Разделы деятельности

В таблице 1.1

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

Таблица 1.1

Условные обозначения диаграммы деятельности

Синтаксис

Имя

Семантика


Начальный узел

Указывает, где
начинается поток, при
вызове деятельности.


Конечный узел
деятельности

Завершает деятельность.


Конечный узел
потока

Завершает определенный
поток деятельности


другие потоки не
затрагиваются.


Узел решения

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

29



Узел слияния

Копирует входные
маркеры в единственное
выходное ребро.


Узел ветвления

Разделяет поток на
несколько параллельных
потоков.



Узел объединения

Синхронизирует
несколько
параллельных
потоков. Может иметь
описание объединения
для изменения его
семантики (не
обязательно).


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

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

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

Задачей второй части ИС является хранение различной информации,
связанной
с тематикой проведения мероприятий:



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

30




Планы проведения мероприятий (сюжет);



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



Учет материального снабжения (количество приходов и расходов,
конечная прибыль);



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



Данные о ведущих и аниматорах.



31



Диаграмма 1.1


Диаграмма деятельности «Обучение»


На второй диаграмме 1.2 показан краткий алгоритм организации
мероприятий.

32


Диаграмма 1.2


Диаграмма деятельности «Организация мероприятия»

33


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


Диаграмма 1.3


Диаграмма деятельности «Персонал»


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


Моделирование прецедентов


это форма выработки требований.
Необходимо осуществить следующие действия:



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



Выявить актеров;



Выявить прецеденты:

-

Сформулировать прецедент;

-

Обозначить основные альтернативные потоки прецедента;



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

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

34


Результат проделанной работы


модель прецедентов. В этой модели
выделены четыре компонента:



Границы системы


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



Актеры


роли, выполняемые людьми или сущностями,
использующими систему.



Прецедент


спецификация
последовательности действий актеров в
системе.



Отношения


значимые связи между актерами и прецедентами.

Граница системы определяется актерами, использующими
моделируемую систему, и конкретными преимуществами
-

прецедентами,
предл
агаемыми системой этим акт
ерам.

Актеры располагаются вне границ
блока, а прецеденты находятся внутри его.

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

взаимодействии с данной системой.

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

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

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


Например, если в системе определен актер Ребенок, то эту роль могут
ис
полнять реальные люди (а конкретнее, в данном примере, дети)


Иван
Иванов, Семен Семенов и многие другие. Одновременно одни и те же люди
35


могут играть и разные роли. Например, Громова Анастасия, являясь
менеджером по продажам, может быть, и администраторо
м, и родителем.

Актеры могут быть изображены в виде пиктограммы класса с указанием
стереотипа «actor» или в виде пиктограммы
«анимационный человечек»,
представленной на рисунке 1.3.



Рисунок 1
.3

-

Варианты изображения актёра.


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


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

Прецедент


это что
-
то, что должна делать система по желанию актера.



Прецеденты всегда инициируются актерами;



Прецеденты всегда описываются с точки зрения актеров.

Каждому прецеденту должно быть присвоено короткое описательное имя,
представляющее собой глагольную группу (в конце концов, прецедент
обозначает
«
выполнить
»

что
-
нибудь).


Отношения


это семантические (значимые) связи между элементами
модели.

Типы отношений:

36




Между актерами и прецедентами (ассоциация);



Между прецедентами и прецедентами (обобщение, «inclu
de
»,
«
extend
»);



Между актерами и актерами (обобщение).

Отн
ошение между актерами и прецедентами обозначается сплошной
линией. Это символ ассоциации в UML. Ассоциация между актером и
прецедентом показывает, что актер и прецедент каким
-
то образом
взаимодействуют.

Связь
DirectedAssociation

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

Обобщение


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


Рисунок 1.
4

-

Иерархия обобщения.


37


Два элемента подчиняются принципу замещаемости: более специальный
элемент

может использоваться в любом месте предполагаемого
использования б
олее общего элемента

без нарушения системы.


«
Include
» (включить)


отношение между

прецедентами, позволяющее

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

Отношение «
Include
» выносит шаги, общие для нескольких
прецедентов, в
от
дельный прецедент, который затем

включается в остальные.


Включающий прецедент называется

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

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


Рисунок 1.
5

-

Отношение «
Include
».

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

прецедент.

Базовый прецедент предоставляет набор точек расширения (
extension

points
). Это точки

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

ряд

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

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

на рисунке 1.6
, отношение «
extend
» может
38


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

Базовый прецедент ничего не знает о расширяющих прецедентах, он
просто предоставляет для них точки входа.

Базовый прецедент не требует

расширений.


Рисунок 1.
6

-

Отношение «
extend
».


«
extend
» (расширить)


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

поведения другого.


Примечания


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

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


Одним из наиболее важных (и доро
гостоящих) этапов проектирования

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

разработчиками будут
восприняты

не корректно, то в итоге заказчик может

получить систему,
совсем не соответствующую его ожиданиям
. Моделирование пр
ецедентов и
актеров помогает

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

демонстрации и обсуждения
диаграммы прецедентов. Прецеденты и актеры


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

39



Диаграмма вариантов для данной моделируемой информационной
системы разбита на две части.


1.8. Модель этапа анализа

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

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

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

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

В дополнение к диаграммам приводится описание основных потоков
прецедентов.

40


Диаграмма 1.4 является базовой

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


Диаграмма 1
.4

-

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


Описание
прецедентов, изображенных на диаграмме 1.4:

Имя прецедента.
Подготавливает мероприятие.

Сводка.
Сотрудники готовят детское мероприятие.

Актёр.
Сотрудник, Ребенок.

Предусловие.
Поступает предложение проведения мероприятия.


Основной поток событий:

1.

Сотрудник решает вопрос о рентабельности мероприятия;

А1. Сотрудник решает организационные вопросы мероприятия;

А2. Сотрудник проводит работу с финансовой стороной мероприятия;

А3. Мероприятие нерентабельно.

41


Альтернативные потоки:

А1. Сотрудник решает орг
анизационные вопросы мероприятия;

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


А2. Сотрудник проводит работу с финансовой стороной мероприятия;

Данный альтернативный поток

рассматривается в прецеденте
«Проводит работу с финансовой стороной» под диаграммой 1.5.


А3. Мероприятие нерентабельно:

1.

Мероприятие не проводится.

Постусловие:
Все данные мероприятия занесены в ИС.

Имя прецедента.
Ведет журнал посещаемости.

Сводка.
Сотрудник ведет журнал посещаемости.

Актёр.
Администратор, Ребенок.

Предусловие.
Наличие списков учащихся, групп и факультативов.

Основной поток событий:

1.

Начинается занятие;

А1. Ребенок отсутствует на занятии.

2.

Ребенок п
рисутствует на заня
тии;

4.

Администратор отмечает

в журнале посещаемости
присутствие
ребенка

Альтернативные потоки:

А1. Ребенок отсутствует на занятии:

1.

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

Постусловие:
Все данные о посещаемости занесены в ИС.

Им
я прецедента.
Работает с сотрудниками.

Сводка.
Администратор работает с клиентами.

Актёр.
Администратор, Сотрудник.

Предусловие.

42


Основной поток событий:

1.

Администратор приступает к работе, связанной с данными
сотрудников;

А1. Администратор фиксирует данн
ые о сотрудниках;

А2. Администратор составляет расписание.

Альтернативные потоки:

А1. Администратор фиксирует данные о сотрудниках.

Данный альтернативный поток рассматривается в прецеденте «Заносит
данные» под диаграммой 1.7.


А2. Администратор составляет расписание.

Данный альтернативный поток рассматривается в прецеденте
«Составляет расписание» под диаграммой 1.7.

Постусловие:
Все данные зафиксированы в ИС.

Имя прецедента.
Работает с клиентами.

Сводка.
Администратор

проводит работу с данными сотрудников.

Актёр.
Администратор, Родитель.

Предусловие.
Родитель изъявляет желание на обучение ребенка в д/с.

Основной поток событий:

1.

Администратор приступает к работе, связанной с данными ребенка.

А1. Администратор фиксирует д
анные ребенка и родителя.

А2. Администратор принимает оплату за услуги д/с;

А3. Помогает в заключении договора с детской студией.

Альтернативные потоки:

А1. Администратор фиксирует данные ребенка и родителя.

Данный альтернативный поток рассматривается в п
рецеденте
«Фиксирует данные» под диаграммой 1.6.

А2. Администратор принимает оплату за услуги д/с.

Данный альтернативный поток рассматривается в прецеденте
«Принимает оплату за услуги» под диаграммой 1.6.

43



А3. Администратор помогает в заключении д
оговора с детской
студией клиентам.


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

Постусловие:
Все данные зафиксированы в ИС.



Диаграмма 1.
5

-

Диаграмма вариантов
использования для детализации
прецедента «Подготавливает мероприятие» актера Сотрудник.


Описание прецедентов, изображенных на диаграмме 1.5:

Имя прецедента.
Проводит работу с организационной частью.

Сводка.
Сотрудник проводит работу с организационной ча
стью.

Данный прецедент входит в прецедент «Подготавливает мероприятие».

Актёр.
Сотрудник, Ребенок.

Предусловие.
Мероприятие рентабельно.

Основной поток событий:

1.

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

2.

Сотрудник составляет план пр
оведения мероприятия;

44


3.

Сотрудник назначает ответственного за мероприятие (при
необходимости подбирает ведущих, аниматоров и других людей,
принимающих участие

в проведении мероприятия);

4.

Сотрудник составляет список необходимых закупок;

5.

Сотрудник оповещает о мероприятии клиентов;

6.

Сотрудник осуществляет закупки;

7.

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

Альтернативные потоки:
нет.

Постусловие:

Все данные зафиксированы в ИС.

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

Сводка.
Сотрудник проводит работу с финансовой стороной мероприятия.

Данный прецедент входит в прецедент «По
дготавливает мероприятие».

Актёр.
Сотрудник, Ребенок.

Предусловие.
Мероприятие рентабельно.

Основной поток событий:

1.

Сотрудник составляет список необходимых закупок;

2.

Сотрудник назначает цену на входные билеты;

3.

Клиенты приобретают билеты;

4.

Сотрудник
осуществляет закупки;

5.

Сотрудник осуществляет оплату услуг по проведению мероприятия
(оплата ведущих, аниматоров, проезда и т.п.).

Альтернативные потоки:
нет.

Постусловие:
Все данные о расходах и приходах зафиксированы в ИС.


Описание прецедентов, изображен
ных на диаграмме 1.6:

Имя прецедента.
Фиксирует данные.

Сводка.
Администратор фиксирует данные ребенка.

Данный прецедент входит в прецедент «Работает с клиентами».

45



Диаграмма 1.
6

-

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

детализации
прецедента «Работает с

клиентами» актера Администратор.


Актёр.
Администратор, Родитель.

Предусловие.
Необходимо занесение новых данных.

Основной поток событий:

1.

Администратор вносит личные данные ребенка (ФИО, дата рождения и
др.);

2.

Администратор вносит личные данные родителя ре
бенка (ФИО, дата
рождения и др.);

3.

Администратор фиксирует ребенка в качестве учащегося конкретной
группы или факультатива.

Альтернативные потоки:
нет.

Постусловие:
Все данные о ребенке зафиксированы в ИС.

Имя прецедента.
Принимает оплату за услуги.

Сводка.
Администратор п
ринимает оплату за услуги д/с.

Данный прецедент входит в прецедент «Работает с клиентами».

Актёр.
Администратор, Родитель.

Предусловие.
Наступило время оплаты.

Основной поток событий:

46


1.

Администратор оповещает родителя о необходимости
оплатить услуги
д/с;

2.

Родитель оплачивает услуги.

Альтернативные потоки:
нет.

Постусловие:
Все данные об оплате зафиксированы в ИС.

Имя прецедента.
Помогает в заключении договора с детской студией.

Сводка.
Администратор помогает в заключении договора с д/
с.

Данный прецедент входит в прецедент «Работает с клиентами».

Актёр.
Администратор, Родитель.

Предусловие.
Необходимость заключения договора.

Основной поток событий:

1.

Администратор выдает бланк договора;

2.

Родитель заполняет и подписывает договор.

Альтернати
вные потоки:
нет.

Постусловие:
Все данные о договоре зафиксированы в ИС.

Диаграмма 1.
7

-

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

детализации
прецедента «Работает с клиентами» актера Администратор.


Описание прецедентов, изображенных на диаграмме 1.7:

Имя прецедента.
Заносит данные.

47


Сводка.
Администратор заносит данные сотрудника.

Данный прецедент входит в прецедент «Работает с сотрудниками».

Актёр.
Администратор, Сотрудник.

Предусловие.
Необходимо занесение новых данных.

Основной поток событий:

1.

Админи
стратор заносит данные сотрудника (ФИО, данные документов
сотрудника и пр.).

Альтернативные потоки:
нет.

Постусловие:
Все данные о сотруднике зафиксированы в ИС.

Имя прецедента.
Составляет расписание.

Сводка.
Администратор составляет расписание.

Данный пр
ецедент входит в прецедент «Работает с сотрудниками».

Актёр.
Администратор, Сотрудник.

Предусловие.
Новое расписание.

Основной поток событий:

1.

Администратор назначает группу или факультатив преподавателю;

2.

Администратор определяет время и день недели проведе
ния занятий;

3.

Администратор указывает номер класса (комнаты) для ведения
занятий.

Альтернативные потоки:
нет.

Постусловие:
Расписание зафиксировано в ИС.















48



2
.
РАЗРАБОТКА ПРОЕКТА И
С


2.1.

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

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

Минимальная форма класса включает следующее:

1.

Имя


обязательно.

2.

Атрибуты


имена атрибутов являются обязательными, хотя на
данном этапе

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

3.

Операции


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

4.

Видимость


обычно не указывается.

5.

Стереотипы


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

6.

Помеченные значения


могут указываться, если это улучшает
модель.

Пример класса анал
иза приведен на рисунке 2.1.


Рисунок
2
.1

-

Пример класса анализа
.


49


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


Признаки хорошего класса ана
лиза можно кратко охарактеризовать
следующим образом:


• его имя отражает его назначение;


• он является четкой абстракцией, моделирующей один
конкретный элемент предметной области;

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

• у него небольшой четко определенный набор обязанностей;

• у него высокая внутренняя связность (cohesion);

• у него низкая связанность с другими классами (coupling).


Анализ существительное/глагол


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


Первый шаг в анализе сущ
ествительное/глагол


собрать максималь
но
возможный объем относящейся к делу информации.


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

источниками информа
ции являются
:


сценарий;


• модель прецедентов;

• документы
концепции.


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


Существительные и именные группы могут служить признаком классов
или атрибутов классов. Глаголы и глагольные группы


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

незамедлительно проконсул
ьтироваться у эксперта в предметной
50


области и добавить этот терми
н в глоссарий проекта. Составляется

список
существительных, именных групп, глаголов

и глагольных групп,
используется

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

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

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


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

Отношения


это способ объе
динения сущностей в UML.

Некоторые типы отношений:


• ассоциация


• обобщение

Ассоциации



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

Ассоциации могут иметь:

• имя ассоциации

• имена ролей

• кратность

• возможность навигации.

51



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


Рисунок 2.2

-

Пример ассоциации.


В примере на рисунке 2.2

ассоциация читается следующим образом:
«Родитель подписывает один или
много Договоров». Хотя стрелка указывает
направление чтения ассоциации, всегда можно прочитать ее в обратном
направлении. Та
ким образом, в примере на рисунке 2.2

мож
но сказать, что в
л
юбой момент времени «каждый Договор заключил только один Родитель».

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

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

52


Спецификация UML 2.0 [UML2S] предлагает три стиля обозначения
возможности навигации на диаграммах модели.

1. Сделать возможность навигации абсолютно явной. Должны быть
обозначены все стрелки и кресты.

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

3. Опускать все кресты. Двунаправленная ассоциация обозначается без
стрел
ок. Однонаправленная ассоциация обозначается с одной стрелкой. Этот
стиль чаще всего

используется на практике (рисунок 2.3
).


Рисунок 2.3

-

Стиль 3.


В ОО моделировании распространена следующая проблема: когда ме
-
жду классами установлено отношение многие

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

Класс
-
ассоциация


это линия ассоциации (включая все имена ролей и
к
ратности), пунктирная

линия и прямо
угольник к
ласса на конце пунктирной
линии, как показано н
а рисунке 2.4.

По сути, класс
-
ассоциация


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

операции и другие ассо
циации.

53



Рисунок 2.4
-

Пример класса
-
ассоциации.


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


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

композитную
агрегацию называют просто композицией.


Агрегация


это свободный тип отношения между объектами


как
между компьютером и его периферийным оборудованием.


Агрегация


это тип отношения целое

-

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

Композиция



это очень строгий тип отношения между объектами


как
между деревом и его листьями.

Ключевое различие между агрегацией и композицией в том, что в
ком

позиции у частей нет независимой жизни вне целого. Более того, в ком
-
позиции каждая часть принадлежит максимум одному и только одно
му
54


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


Рисунок 2.5

-

При
мер
агрегации.



В примере на рисунке 2.6

объекты
Временные возможности

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

может
принадлежать только одному объекту
Преподаватель
. Так же и ли
стья на
деревьях


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


Ри
сунок 2.6

-

Пример композиции.


Зависимость

-

обозначает отношение между двумя или более элемента
-
ми модели, при котором изменение одного элемента (поставщика) мо
жет
55


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

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

З
ависимость

«
use
»

генерируется любой из следующих ситуаций
:

1. Операции класса клиент необходим параметр класса поставщик.

2. Операция класса клиент возвращает значение класса поставщик.

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

Зависимость «call» (вызов) устанавливается между операциями


опе
-
рация
-
клиент вызывает операцию
-

поставщик.

Зависимость «parameter»
-

поставщик является па
раметром операции
клиента.

Зависимость «send»
-

клиент


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

Зависимость «instantiate»
-

клиент


это экземпляр поставщика.

Обобщение


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

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

Дополнение видимости (visibility) (табл. 1) применяется к атрибу
там и
операциям класса.

56


Таблица 2.1

Дополнение

Видимость

Семантика

+

Public (
Открытый
)

Любой элемент, который имеет доступ
к классу, имеет доступ к любой из его
возможностей, видимость которой
public
.

-

Private (
Закрытый
)

Только операции класса имеют доступ
к возможностям, имеющим видимость
private
.

#

Protected
(
Защищенный
)

Только операции

класса или потомка
класса имеют доступ к возможностям,
имеющим видимость
protected
.

~

Package(
Пакетный
)

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



Типом атрибута может быть другой кл
асс или примитивный тип,
описанный в таблице 2.2.

Таблица 2.2

Простой тип

Семантика

Integer

Целое число.

UnlimitedNatural

Целое число
—= 0.

Бесконечность обозначается как *.

Boolean

Может принимать значения
true

или
false
.

String

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

57


2.2.

Разработка моделей

классов.

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


2.8.

Описательная часть диаграммы 2.1:

Объектом

класса
«Ребенок»
является любой ребенок, который может
принять участие в мероприятии. Мероприятия могут быть внутренними
(только для детей д/с) и общедоступными, поэтому класс «
Р
ебенок» обладает
атрибутом «обучени
е в детской студии» типа
Boolean
. Если ребенок
-

учащийся д/с, то данный атрибут имеет значение
true
. Атрибут «ФИО»
является не обязат
ельным. А
трибут «Возраст»
нужен

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

Объектом
клас
са
«Сопровождающий»
является любой взрослый,
который сопровождает на мероприятии ребенка и берущий на себя
ответственность за него. Важным атрибутом класса является «Номер
телефона». Его значение потребуется в случае необходимости связи
организаторов с со
провождающим. Значение атрибута «Статус»
предполагает ответ на вопрос: «Кем приходится Вам ребенок?». Этот атрибут
и все остальные являются не обязательными.

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

Класс «Мероприятие» обладает обязательными атрибутами: название,
дата, общедоступность, место п
роведения (название места), возрастные и
количественные (максимальное количество детей и взрослых) ограничения.

58



Диаграмма 2.1
-

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

59


Объектом класса «Место» может быть любое место, где можно провести
мероприятие. У одного мероприятия может быть несколько мест проведения.
Обязательными из всех атрибутов являются: название, адрес и описание.

Объектами класса «Ведущий» могут являться, как

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

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

План проведения составляется объек
тами класса «Сотрудник».

Описательная часть диаграммы 2.2:

Объект класса

«Покупатель»

-

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


К
ласс

«Входной билет»

обладает следующими обязательными
атрибутами: цена, возрастная особенность (детский/взрослый)
и стоимость
затрат на изготовление билета.

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

взять с собой на мероприятие. Данное
приложение составляется из объектов класса «Памятка для посетителей
мероприя
тия» и класса «Предмет».

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

В

классе

обязательно
указывать все
атрибуты.

60



Диаграмма
2.2

-

Диаграмма классов для п
рецедент
а

«
Проводит работу с финансовой стороной
».

61


Класс «Затраты и приходы», «Операция с расходом или приходом» и
класс
-
ассоциация «Затраты и приходы по операции» задействованы в
ведении учета денежных средств. Они необходимы для составления
финансовой отчетности по проведенной работе.

Объектом

класса
«
Изделие»
является предмет, используемый для
проведения мероприятий д/с. Данный класс более полно характеризуют
объекты других классов: Материал, Приспособления, Контакт (список мест
возможной покупки данного предмета) и Дополнительные расходы
(например, до
ставка). Объектами класса
-
ассоциации «Необходимые
изделия» являются предметы, которые необходимы для проведения данного
мероприятия. Класс
-
ассоциация обладает обязательными атрибутами: номер,
название, наличие и стоимость. Остальные атрибуты не обязательн
ы.

Описательная часть диаграммы 2.3:

Объектом

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

Задачей объе
кта класса «Сотрудник » является безошибочное занесение
данных ребенка в базу данных и помощь в выборе группы и/или
факультатива для дальнейшего обучения ребенка.

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

Как только ребенка определят к конкретной группе или факультативу,
он становиться учащимся д/с. На диаграмме присутствует класс
-
ассоциация
«Учащийся», позволяющий выводить информацию о ребенке

и группе,
делать отчеты и собирать статистические данные.



62


Диаграмма
2.3

-

Диаграмма классов для п
рецедент
а

«
Фиксирует данные
».



63


Описательная часть диаграммы 2.4:

Объект класса «Родитель» оплачивает услуги за обучение ребенка
сотруднику детской студии. Все атрибуты класса
обязательны: ФИО

(родителя), ФИО ребенка (за обучение которого вносится плата), номер
телефона (родителя), паспортные данные (родителя),
e
-
mail

и
адрес.

Информация о стоимости обучения в группе или факультативе
содержится в классе «Группа и факультатив».

Класс
-
ассоциация «Оплата» позволяет делать отчеты, связанные с
оплатой за обучение.



Диаграмма
2.4

-

Диаграмма классов для п
рецедент
а

«
Принимает

оплату
за услуги
».

Описательная часть диаграммы 2.
5
:

Объект класса «Группа»


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

64



Диаграмма
2.5

-

Диаграмма классов для п
рецедент
а

«
Составляет расписание
»
.



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

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

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


2.3.

Microsoft

Visio
.

Важнейшим компонентом любой информационной системы

является

База данных
.
База данных (Data Base)



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

Цель создания
модели данных
состоит в обеспечении разработчика
ИС

конце
птуальной

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

Microsoft Visio



это мощное решение для создания диаграмм, которое
позволяет упростить и

связать и
нформацию, а

также поделиться

ей.
Интерфейс Microsoft Visio обладает

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

С

помощью Visio можно легко создавать диаграммы, используя
встроенные интеллектуальные фигуры и

шаблоны, созданны
е корпорацией
Майкрософт и

ее

партнерами.

Диаграммы Visio можно связывать с

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

реальном времени.

С помощью данного специализированного средства были построены
ER
-
диаграммы

для ИС,
представленной в моей дипломной работе.

66



2.4.

ER
-
диаграмма
.

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


данных, что

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

(
ER


Entity
-
Relationship
)


ERD
.

Существуют различные варианты отображения
ERD,
но все варианты
диаграмм сущность
-
связь

исходят из одной идеи


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

ER
-
диаграммы

используют графичес
кое
изображение
сущностей

предметной области, их свойств (
атрибутов
), и
взаимосвязей

между сущностями.

Сущность

(таблица, отношение)


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

Экземпляр сущности

(запись, кортеж)
-

это конкретный представитель
данной сущности.

Атрибут сущности

(поле, домен)


это именованная характеристика,
являющая
ся некоторым свойством сущности.

Связь



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




67


2.5.

Построение

ER
-
диаграмм

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

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

На диаграммах 2.6


2.10 представлены
ERD

для проектируемой ИС
дипломной работы.

Диаграммы достаточно понятны и не требуют отдельного
описания. Но необходимо разъяснить такие понятия, ка
к
FK

и
PK
, часто
встречающиеся на данных диаграммах.

Обычно в таблице есть столбец или комбинация столбцов, содержащих
значения, уникально определяющие каждую строку таблицы. Этот столбец,
или столбцы, называются первичным ключом (PK) таблицы и обеспечивае
т
целостность сущности таблицы. Можно создать первичный ключ, задав
ограничение PRIMARY KEY при создании или изменении таблицы.

В таблице может быть только одно ограничение PRIMARY KEY, и
столбец с данным ограничением не может содержать значения NULL. Из
-
з
а
того, что ограничения PRIMARY KEY гарантируют уникальность данных,
они часто определяются в столбце идентификаторов.

Внешний ключ (FK)


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

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


68








Диаграмма
2.6



ERD

«Работа

с организационной частью

проведения
мероприятия
».

Модель части БД, отвечающей за финансовую сторону организации
мероприятий, была разбита на две
ER
-
диаграммы (диаграммы 2.7 и 2.8) для
улучшения качества восприятия диаграммы.

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

69









Диаграмма
2.7



ERD

«Работа

с
фи
нансовой стороной проведения
мероприятия
»
, часть 1
.


На диаграмме 2.8 модель БД , связанная с операциями по закупкам
необходимых атрибутов для проведения мероприятия. Оплата ведущих и
аниматоров фиксируется в классе «Необходимые изделия», так я считаю
выд
еление на данную операцию целого класса бессмысленным.

70



Диаграмма
2.8



ERD

«Работа

с
финансовой стороной проведения
мероприятия
»
, часть 2
.


На диаграмме 2.9 опущен класс «Факультатив», из
-
за схожести с
классом «Группа», но в БД ИС он присутствует.




71




Диаграмма
2.9



ERD

«Данные учащегося
»
.


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

72





Диаграмма
2.10



ERD

«Оплата обучения
»
.


Количество приведенных
ER
-
диаграмм считаю достаточным для
создания представления о БД разрабатываемой ИС.














73


3.

РЕАЛИЗАЦИЯ ФРАГМЕНТО
В ИС


3.1.

Описание программного инструмента
Dbforge

D
bForge Studio for MySQL


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


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



3.2.

Разработка базовых структур и типовых запросов

Каждая
сущность

в
ER
-
диаграмме

представляет собой
таблицу

базы
данных.

Разработанн
ые выше

ER
-
диаграммы

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

не учитывающей особенности к
онкретной СУБД. На основе
данных концептуальных диаграмм была построена

физическая модель
,
которая будут учитывать такие особенности СУБД, как допустимые типы,

на
именования полей и таблиц, ограничения целостности и т.п.



Каждый
атрибут

становится колонкой (
полем
) соответствующей
таблицы.

74






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



Рисунок

3.1


Таблица
«Мероприятие».

Ограничение целостности

-

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

База
данных находится в согласованном (целостном
)

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


При проектировании БД главной задачей является

в
ыявление

все
х
имеющихся ограничений целостности и отражение

их в базе данных.

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

75



Рисунок 3.2


Ограничения в таблице «Мероприятие».


SQL (Structured Query Language


Структурированный язык запросов)


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

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

Создание таблицы «Мероприятие»
:

CREATE

TABLE

studio
.мероприятие (


`
Код

мероприятия
`
int
(11)
UNSIGNED

NOT

NULL

AUTO
_
INCREMENT
,


Тема

varchar
(100)
NOT

NULL
,


`Дата мероприятия` date NOT NULL,


Общедоступность tinyint(1) UNSIGNED DEFAULT NULL,


`Количественные ограничения`
int
(11)
UNSIGNED

DEFAULT

NULL
,


`Минимальный возраст`
int
(11)
UNSIGNED

DEFAULT

NULL
,


`Максимальный возраст`
int
(11)
UNSIGNED

DEFAULT

NULL
,


`Код места` int(11) UNSIGNED NOT NULL,


`Код ПП` int(11) UNSIGNED NOT NULL,


`Код ведущего` int(11) UNSIGNED NOT NULL,


PRIMARY KEY (`Код мероприятия`),


CONSTRAINT `FK_мероприятие_место_Код места` FOREIGN KEY (`Код
места`)


REFERENCES studio.место (`Код места`) ON DELETE RESTRICT ON
UPDATE RESTRICT,


CONSTRAINT

`
FK
_мероприятие_план проведения_ Код ПП`
FOREIGN

KEY

(`Ко
д ПП`)

76



REFERENCES studio.`план проведения` (` Код ПП`) ON DELETE
RESTRICT ON UPDATE RESTRICT,


CONSTRAINT

`
FK
_мероприятие_ведущий_Код ведущего`
FOREIGN

KEY

(`Код ведущего`)


REFERENCES studio.ведущий (`Код ведущего`) ON DELETE RESTRICT
ON UPDATE RESTRI
CT

)

ENGINE = MYISAM

AUTO_INCREMENT = 1

CHARACTER SET cp1251

COLLATE cp1251_general_ci

ROW_FORMAT = fixed;

В таблицу «Мероприятие», для примера , были введены данные, показанные
на рисунке 3.3.

Рисунок 3.3


Пример данных таблицы «Мероприятие».


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

и примеры
данных.


77



Рисунок 3.4
-

Таблица «Ребенок».



Рисунок 3.5


Ограничения в таблице «Ребенок».


Создание таблицы «Ребенок»:

CREATE

TABLE

studio
.ребенок (


`Код ребенка` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,


Фамилия varchar(25) NOT NULL,


Имя varchar(15) NOT NULL,


Отчество varchar(15) NOT NULL,


Пол char(1) NOT NULL,


`Дата рождения` date NOT NULL,


Город varchar(30) DEFAULT NULL,


Улица varch
ar(30) DEFAULT NULL,


Дом int(3) DEFAULT NULL,


Корпус int(3) DEFAULT NULL,

78



Квартира int(3) DEFAULT NULL,


PRIMARY KEY (`Код ребенка`)

)

ENGINE = MYISAM

AUTO_INCREMENT = 1000

AVG_ROW_LENGTH = 141

CHARACTER SET cp1251

COLLA
TE cp1251_general_ci;


Рисунок 3.6


Пример данных таблицы «Ребенок».




Рисунок 3.7
-

Таблица «Ребенок, не обучающийся в д/с».




Рисунок 3.8


Ограничения в таблице «Ребенок, не обучающийся в д/с».


79


Создание таблицы «Ребенок, не обучающийся в д/с»
:

CREATE TABLE
studio.`ребенок, не обучающийся в д/с` (


`
Номер

ребенка

НУ
` int(11) UNSIGNED NOT NULL
AUTO_INCREMENT,


Фамилия

varchar(25) DEFAULT NULL,


Имя

varchar(15) NOT NULL,


Отчество

varchar(15) DEFAULT NULL,


`
Дата

рождения
` date NOT NULL,


PRIMARY KEY
(`Номер ребенка НУ`)

)

ENGINE = MYISAM

AUTO_INCREMENT = 5

CHARACTER SET cp1251

COLLATE cp1251_general_ci

ROW_FORMAT = fixed;



Рисунок 3.9


Пример данных таблицы «Ребенок, не обучающийся
в д/с».



80



Рисунок 3.10
-

Таблица «Сопровождающий».



Рисунок 3.11


Ограничения в таблице «Сопровождающий».


Создание таблицы «Сопровождающий»
:

CREATE

TABLE

studio
.
сопровождающий

(


`
Код

сопровождающего
` int(11) UNSIGNED NOT NULL
AUTO_INCREMENT,


Фамилия

varchar(25) DEFAULT NULL,


Имя

varchar(15) DEFAUL
T NULL,


Отчество

varchar(15) DEFAULT NULL,


Статус

varchar(10) DEFAULT NULL,


`
Номер

телефона
` int(11) UNSIGNED NOT NULL,


`e
-
mail` varchar(25) DEFAULT NULL,


`
Код

ребенка
` int(11) UNSIGNED DEFAULT NULL,


`
Код

ребенка

НУ
` int(11) UNSIGNED DEFAULT
NULL,

81



PRIMARY KEY (`Код сопровождающего`),


CONSTRAINT `FK_сопровождающий_ребенок_Код ребенка`
FOREIGN KEY (`Код ребенка`)


REFERENCES studio.
ребенок

(`
Код

ребенка
`) ON DELETE RESTRICT
ON UPDATE RESTRICT,


CONSTRAINT `FK_сопровождающий_ребенок, не обу
чающийся в
д/с_Номер ребенка НУ` FOREIGN KEY (`Код ребенка НУ`)


REFERENCES studio.`
ребенок
,
не

обучающийся

в

д
/
с
` (`
Номер

ребенка

НУ
`) ON DELETE RESTRICT ON UPDATE RESTRICT

)

ENGINE = MYISAM

AUTO_INCREMENT = 1

CHARACTER SET cp1251

COLLATE cp1251_general_
ci

ROW_FORMAT = fixed;

Рисунок 3.12


Пример данных таблицы «Сопровождающий».



82


Рисунок 3.13
-

Таблица «Приглашенный».


Рисунок 3.14


Ограничения в таблице «Приглашенный».



Создание таблицы «Приглашенный»
:

CREATE

TABLE

studio
.приглашенный (


`Номер

приглашенного` int(11) UNSIGNED NOT NULL
AUTO_INCREMENT,


`Код мероприятия` int(11) UNSIGNED NOT NULL,


`Код ребенка` int(11) UNSIGNED DEFAULT NULL,


`Код ребенка НУ` int(11) UNSIGNED DEFAULT NULL,


PRIMARY

KEY

(`Номер приглашенного`),


CONSTRAINT

`
F
K
_приглашенный_мероприятие_Код мероприятия`
FOREIGN

KEY

(`Код мероприятия`)


REFERENCES studio.мероприятие (`Код мероприятия`) ON DELETE
RESTRICT ON UPDATE RESTRICT,

83



CONSTRAINT

`
FK
_приглашенный_ребенок_Код ребенка`
FOREIGN

KEY

(`Код ребенка`)


REFERENCES studio.ребенок (`Код ребенка`) ON DELETE RESTRICT
ON UPDATE RESTRICT,


CONSTRAINT

`
FK
_приглашенный_ребенок, не обучающийся в
д/с_Номер ребенка НУ`
FOREIGN

KEY

(`Код ребенка НУ`)


REFERENCES studio.`ребенок, не обучающийся в д/с` (`Номер ребенк
а
НУ`) ON DELETE RESTRICT ON UPDATE RESTRICT

)

ENGINE = MYISAM

AUTO_INCREMENT = 1

CHARACTER SET cp1251

COLLATE cp1251_general_ci;


Рисунок 3.15


Пример данных таблицы «Приглашенный».


Рисунок 3.16
-

Таблица «План проведения».


84


Рисунок 3.17


Ограничения в таблице «План проведения».


Создание таблицы «План проведения»
:

CREATE

TABLE

studio
.`
план

проведения
` (


`
Код

ПП
`
int
(11)
UNSIGNED

NOT

NULL

AUTO_INCREMENT,


Описание text NOT NULL,


PRIMARY KEY (` Код ПП`)

)

ENGINE =
MYISAM

AUTO_INCREMENT = 1

CHARACTER SET cp1251

COLLATE cp1251_general_ci;



Рисунок 3.18


Пример данных таблицы «План проведения».



Рисунок 3.19
-

Таблица «Место».


85



Рисунок 3.20


Ограничения в таблице «Место».


Создание таблицы «Место»
:

CREATE

TABLE

studio
.место (


`
Код

места
`
int(11) UNSIGNED NOT NULL AUTO_INCREMENT,


Название varchar(25) NOT NULL,


Адрес varchar(50) NOT NULL,


`Имя контактного лица` varchar(15) DEFAULT NULL,


`Номер телефона` int(11) DEFAULT NULL,


`e
-
mail` varchar(25) D
EFAULT NULL,


Описание text NOT NULL,


Отзыв text DEFAULT NULL,


PRIMARY KEY (`Код места`)

)

ENGINE = MYISAM

AUTO_INCREMENT = 1

CHARACTER SET cp1251

COLLATE cp1251_general_ci

ROW_FORMAT = fixed;




Рисунок 3.21


Пример данных таблицы «Место».


86



Рисунок 3.22
-

Таблица «Ведущий».



Рисунок 3.23


Ограничения в таблице «Ведущий».


Создание таблицы «Ведущий»
:

CREATE

TABLE

studio
.ведущий (


`
Код

в
едущего` int(11) UNSIGNED NOT NULL AUTO_INCREMENT,


Фамилия varchar(25) NOT NULL,


Имя varchar(15) NOT NULL,


Отчество varchar(15) NOT NULL,


`Номер телефона` int(11) NOT NULL,


`e
-
mail` varchar(25) NOT NULL,


Адрес varchar(50) NOT NULL,


PRIMARY KEY (`Код ведущего`)

)

ENGINE = MYISAM

AUTO_INCREMENT = 1

CHARACTER SET cp1251

COLLAT
E cp1251_general_ci

87


ROW_FORMAT = fixed;



Рисунок 3.24


Пример данных таблицы «Ведущий».


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

(query).

Рассмотрим примеры запросов.

Запрос краткой характеристики мероприятия:

SELECT


место.Название AS `Название места`,


место.Адрес AS `Адрес места`,


место.Описание AS `Описание места`,


`план проведения`.Описание AS
`План мероприятия`,


ведущий.Фамилия AS `Фамилия ведущего`,


ведущий.Имя AS Имя,


ведущий.Отчество AS Отчество,


ведущий.`Номер телефона` AS `Тел ведущего`

FROM мероприятие


INNER JOIN место


ON мероприятие.`Код места`  место.`Код места`


INNER JOIN `план проведения`


ON мероприятие.`Код ПП`  `план проведения`.` Код ПП`


INNER JOIN ведущий


ON мероприятие.`Код ведущего`  ведущий.`Код ведущего`


88


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



Рисунок 3.25


График запроса краткой характеристики мероприятия.


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


89



Рисунок 3.26


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


На рисунке 3.27 показан пример результата проделанного запроса.



Рисунок 3.27


Пример результата
запроса
краткой характеристики
мероприятия.


Запрос списка приглашенных детей из
д/с:

SELECT


приглашенный.`Номер приглашенного` AS Номер,


мероприятие.Тема AS Мероприятие,


ребенок.Фамилия,


ребенок.Имя

FROM приглашенный


INNER JOIN мероприятие


ON приглашенный.`Код мероприятия`  мероприятие.`Код
мероприятия`

90



INNER JOIN реб
енок


ON приглашенный.`Код ребенка`  ребенок.`Код ребенка`





Рисунок 3.28


График запроса списка приглашенных детей из д/с.



Рисунок 3.29


Требования к запросу
списка приглашенных детей из д/с.




Рисунок 3.30


Пример результата
запроса
спи
ска приглашенных детей
из д/с.


91



Запрос списка приглашенных детей «со стороны»:


SELECT


приглашенный.`Номер приглашенного` AS Номер,


мероприятие.Тема AS Мероприятие,


`ребенок, не обучающийся в д/с`.Имя AS Имя

FROM приглашенный


INNER JOIN мероприятие


ON приглашенный.`Код мероприятия`  мероприятие.`Код
мероприятия`


INNER JOIN `ребенок, не обучающийся в д/с`


ON приглашенный.`Код ребенка НУ`  `ребенок, не обучающийся в
д/с`.`Номер ребенка НУ`




Рисунок 3.31


График
запроса списка приглашенных детей «со
стороны».


92



Рисунок 3.32


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





Рисунок 3.33


Пример результата
запроса
списка приглашенных детей
«со стороны».




Запрос сопровождающего:

SELECT


ребенок.Фамилия AS `Фамилия ребенка`,


ребенок.Имя,


сопровождающий.Статус,


сопровождающий.Фамилия AS `Фамилия сопровождающего`,


сопровождающий.Имя,


сопровождающий.Отчество

FROM сопровождающий


INNER JOIN ребенок


ON сопровождающий.`Код ребен
ка`  ребенок.`Код ребенка`


93




Рисунок 3.34


График запроса сопровождающего.



Рисунок 3.32


Требования к запросу
сопровождающего.



Рисунок 3.33


Пример результата
запроса
сопровождающий.







94



ТЕХНИКО
-
ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ.


4.1

Обоснование
целесообразности разработки проекта

Текущий
период жизни

охарактеризован
повышением роли информации
в развитии

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

новых,
более совершенных информационных технологий,
необходимых для сбора и

обработки информации. С развитием такого
общества

появляется
необходимость в

разработке новых
информационных
систем, которые

позволяли бы
руководителям и

сотрудникам
организаций в

любой момент
времени получать достоверные и

актуальные
сведения,

корректиро
вать расписание мероприятий
и формировать отчеты, содержащие
краткую

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

Владельцы детских студий или

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

над

деятельностью
организации.

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

нужной
информации

возможен зачастую
только с

использованием
современных
информационных технологий. Одним из

наиболее
эффективных

способов
решения

этой проблемы становится
автоматизация
учета посетителей и

мероприятий в детской студии.
На

сегодняшний день
существует

немало
решений задачи автоматизации

деятельности
организаций, и, как правило, эти решения требуют

значительных
финансовых вложений для

приобретения или обновления
оборудования и
соответствующего

ему
программного обеспечения. Задача автоматизации

детской студии
усложняется,

если она расположена
в

каком
-
либо
регионе,
где доходы от данного вида деятельнос
ти меньше и

возможности по
автоматизации

снижены ввиду
отсутствия

сервисных центров рядом со
студией детского
развития.

95


Повысить

рейтинг
детского центра

относительно
конкурентов,

вне
зависимости
от его

локации
и

величины
капитала,

равно как
и улучшить
кач
ество обслуживания и контроль над

работой студии,

может
система
автоматизации учета информации

о посетителях
и

сотрудниках детской
студии.

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

В создании
системы

принимали участие
как технические специалисты,
которые

могут
обеспечить

надлежащую
защиту д
анных,

так и профильные:
директор детской студии,

администратор
центра

раннего
развития ребенка,

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

учитывающая особую
специфику и

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

студий
и центро
в

раннего
развития.

В

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

системы для
поддержки
деятельности

детской студии. Определена экономическая оценка

затрат, возникающих при

проведени
и разработки ИС
,

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


4.2

Планирование комплекса работ по разработке темы и оценка
трудоемкости

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

Для

определения ожидаемой продолжительности работы
Т
ож
применяется формула
:

,


где
t
мин



наименьшая

продолжительность данной работы (оптимистическая
оценка);

96



t
макс



наибольшая

продолжительность работы (пессимистическая
оценка);


t
нв



наиболее вероятная продолжительность работы (реалистическая
оценка).

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

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


Таблица 4.1


Оценка трудоемкости отдельных видов работ

Виды

работ

Оптимисти
ческая
оценка
,

t
min
,
дни

Реалистиче
ская
оценка,

t
нв
,

дни

Пессимисти
ческая
оценка,

t
max
.
дни

Ожидаемая

продолжительность

работы,

Т
ож
,

дни

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

2

3

5

3

2.
Сбор исходных
данных

12

18

20

17

3.
Анализ
существующих
методов
решения задачи
и программных
средств

2

3

4

3

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

12

16

18

16

97



1.

Т
ож 
(2+4*3+5)
/6

≈ 3

дня.

2.

Т
ож 
(
12+4*18+20
)
/6



17 дней.

3.

Т
ож 
(
2+4*3+4
)
/6

≈ 3

дня.

4.

Т
ож 
(
12+4*16+18
)
/6



16 дней.

5.

Т
ож 
(
15+4*18+20
)
/6



18 дней.

6.

Т
ож 
(
7+4*10+12
)
/6



10 дней.

7.

Т
ож 
(
10+4*14+18
)
/6



14 дней.

8.

Т
ож 
(
6+4*10+14
)
/6



10 дней.

9.

Т
ож 
(
5+4*7+8
)
/6



7 дней

10.

Т
ож 
(
7+4*14+18
) ≈

13 дней

Разработан календарный график
выполнения работ, приведенный в
таблице 4.2. Он показывает

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

Таблица

4.2

5.
Разработка
модели
предметной
области

15

18

20

18

6.
Разработка
модели системы
хранения
данных

7

10

12

10

7.
Разработка
базы данных

10

14

18

14

8.
Тестирование
базы данных

6

10

14

10

9.
Проведение
экономических
расчетов

5

7

8

7

10.
Оформление
пояснительной
записки

7

14

18

13

98


Календарный график выполнения работ


Вид работ

Исполнители

Длительность,
дни

График работ

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

Руководитель

Инженер

2

3

11.01.16
-
12.01.16

11.01.16
-
13.01.16

2 Сбор исходных данных

Руководитель

Инженер


5

17

14.01.16
-
18.01.16

14.01.16
-
30.02.16

3 Анализ существующих
методов решения задачи и
программных средств

Руководитель

Инженер


1

3

31.01.16

31.01.16
-
02.02.16

4
Определение
функциональности и
поведения системы

Руководитель

Инженер

3

16

03.02.16
-
05.02.16

03.02.16
-
18.02.16

5
Разработка модели
предметной области

Руководитель


Инженер

3

18

19.02.16
-
21.02.16

19.02.16
-

07.03.16

6
Разработка модели системы
хранения данных

Руководитель

Инженер

2

10

08.03.16
-
09.03.16

08.03.16
-
17.03.16

7
Разработка базы данных

Руководитель

Инженер

2

14

18.03.16
-
19.03.16

18.03.16
-
31.03.16

8
.
Тестирование базы данных

Руководитель

Инженер

2

10

01.04.16


02.04.16

01.04.16

10.04.16

9
Проведение экономических
расчетов

Инженер


7

11.04.16

17.04.16

10
Оформление
пояснительной записки


Руководитель

Инженер

1

13

18.04.16

18.04.16
-

30.04.16





99


4.3

Расчет заработной платы и социальных отчислений исполнителей

Дневная ставка

заработной платы

определяется путем разделения
заработной платы

(оклад) за месяц на количество рабочих дней в месяце (21
рабочий день).

Ч
асо
вая ставка

заработной платы
вычисляет
ся исходя из заработной
платы

(оклад) за месяц
разделенной
на количество рабочих часов в месяце
(21 рабочий день х 8 часов  168 часов).

Оклад Руководителя


70
000 руб.

Оклад Инженера


45
000 руб.

Дневная ставка Руководителя


3333,33 руб/день.

Дневная с
тавка Инженера


2142,86 руб/день.

Часовая ставка Руководителя


416,67 руб/час.

Часовая ставка Инженера


267,86 руб/час.


Таблица

4.3

Расчет заработной платы исполнителей


Вид работ

Исполнители

Оплата

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

Руководитель

Инженер

6666,66

6428,58

2 Сбор исходных данных

Руководитель

Инженер


16

666,65

36428,62

3 Анализ существующих
методов решения задачи и
программных средств

Руководитель

Инженер


3333,33

6428,58

4
Определение
функциональности и поведения
системы

Руководитель

Инженер

9999,99

34285,76

5
Разработка модели
предметной области

Руководитель


Инженер

9999,99

38571,48

100


6
Разработка модели системы
хранения данных

Руководитель

Инженер

6666,66

21428,60

7
Разработка базы данных

Руководитель

Инженер

6666,66

30000,04

8
.
Тестирование базы данных

Руководитель

Инженер

6666,66

21428,60

9
Проведение экономических
расчетов

Инженер


15000,02

10
Оформление пояснительной
записки


Руководитель

Инженер

3333,33

27857,18

Итого



307857,45


Расходы на основную заработную плату
исполнителей определяются
по формуле:

,

где

-

расходы на основную заработную плату исполнителей (руб.);
k



количество исполнителей;

-

время, затраченное
i
-
м исполнителем на
проведение исс
ледования (дни или часы);
-

ставка
i
-
го исполнителя
(руб./день или руб./час).

Заработная плата исполнителей по каждому виду
работ указана в таблице 4.3.

 (21*3333,33) + (111*2142,86) 307857,45 руб.

Расходы на д
ополнительную заработную плату исполнителей
определяются по формуле:

,

где

-

расходы на дополнительную заработную плату исполнителей
(руб.);

-

расходы на основную заработную плату исполнителей (руб.);

-

норматив дополнительной заработной платы (%).

 307857,45 * 0,14 43100,04 руб.

1
01


Отчисления единого социального налога

с основной и дополнительной
за
работной платы исполнителей определяются по формуле:

,

где

-

отчисления
ЕСН

с заработной платы (руб.);

-

расходы на
основную заработную плату исполнителей (руб.);

-

расходы на
дополнительную заработную плату исполнителей (руб.);

-

норматив
отчислений
ЕСН

(%). В настоящее время норматив
ЕСН
составляет 30%.

 (307857,45+43100,04)*0,3 105287,25 руб.


4.4

Расчет затрат на сы
рье и материалы

Расчеты

затрат на материалы приведены в таблице 4.4.

Таблица

4.4

Затраты на материалы

Описание

Производитель

Единица
измерения

Количество

Цена за
единицу,
руб.

Сумма
, руб.

Ноутбук

HP

шт

1

25990,00

25990,00

Принтер

RICOH

шт

1

3999,00

3999,00

Карта памяти

Transcend

шт

1

550,00

550,00

Бумага для
оргтехники


шт

1

225
,00

225,00

Канцелярские
товары

-----

-----

-----

1050,00

1050,00

Итого





31814,00

102


Транспортные расходы


3100,00 руб.


4.5

Расчет затрат, связанных

с со
держанием и эксплуатацией
оборудования

Затраты на содержание и эксплуатацию оборудования определяются из
расчета на 1 час работы оборудования с учетом стоимости и
производительности оборудования:

,

где
-

затраты на содержание и эксплуатацию оборудования (руб.);

-

расчетная себестоимость одного машино
-
часа работы оборудования на
i
-
й
технологической операции (руб./м
-
ч);

-

количество машино
-
часов,
затрачиваемых на выполнение
i
-
й технологической операции (м
-
ч).

Таблица 4.5

Затраты на содержание и эксплуатацию

Наименование

Сумма, руб

Ноутбук

489,60

Принтер

0,60

Итого

490,20


4.6

Расчет затрат на амортизационные отчисления

Амортизационные отчисления по основному средству
i

за год
определяются как:

,

где




амортизационные отчисления за год по
i
-
му основному средству
(руб.);



первоначальная стоимость
i
-
го основного средства (руб.);




годовая норма амортизации
i
-
го основного средства (%).

Амортизируемое имущество
-

ноутбук

103


=
5198 руб/год

Величина амортизационных отчислений по
i
-
му основному средству,
используемому студентом при работе над ВКР, определяется по формуле:

,

где


-

амортизационные отчисления по
i
-
му основному средству,
используемому студентом в работе над ВКР (руб.);



амортизационные
отчисления за год по
i
-
му основному средству (руб.);



время, в течение
которого студент использует
i
-
ое основное средство (мес.).


 1472,77 руб.


4.7

Расчет накладных расходов

Накладные расходы
представлены в таблице 4.6.

Таблица 4.6

Накладные расходы

Наименование

Стоимость,руб

Электроэнергия

1530,00


4.8

Расчет общей величины затрат

Таблица 4.6
-

Смета затрат на ВКР



п/п

Наименование статьи

Сумма, руб

1.

Расходы на оплату труда

350957,49

2.

Отчисления на социальные нужды

105287,25

3.

Материалы

349
14,00

104


4
.

Расходы на содержание и эксплуатацию
оборудования

490,20

5
.

Амортизационные отчисления

1472,77

6
.

Накладные расходы

1530,00

ИТОГО затрат

494

651,71



Диаграмма 4.1


Процентное
соотношение статей затрат на ВКР


4.9

Вывод

Проанализировав затраты можно сделать вывод,

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

По
данным расчётам, себестоимость конечного продукта составляет:
494

651,71

руб.
9
0 коп
.

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


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





























106


ЗАКЛЮЧЕНИЕ

В любой организации

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

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


:



Выполнен анализ предметной области
;



Опре
делены функциональные требования к ИС
;



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



Выполнена модель этапа анализа
;



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



Разработана концептуальная модель проекта
;



Разработаны базовы
е структуры и типовые запросы
;



Выполнено технико
-
экономическое обоснование работы
.

Использование информационной системы, разработанной в рамках
дипломного проекта:



Улучшит визуальное восприятие информации;



Сократит время на поиск информации;



Предотвратит
ошибки в обработке информации;

107




Предоставит удобные формы отчетности;



Снизит трудоемкость.

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

С
проектированная система вполне
может быть реализована и использована в данном
учреждении

и в ряде
других
учреждений, схожих

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














108


СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1.

Фаулер M. UML. Основы, 3
-
е издани
е.


Пер. с англ.


СПб: Символ
-
Плюс, 2004.


192 с., ил.

2.

Буч, Г.; Рамбо, Д.; Джекобсон, А. UML. Руководство пользователя; М.:
ДМК Пресс; Издание 2
-
е, стер.
-

Москва,
2010
.
-

432

c.

3.

Леоненков Александр Самоучитель UML 2; БХВ
-
Петербург
-

Москва,
2011
.
-

576 c
.

4.

Туманов, В.Е. Основы проектирования реляционных баз данных;
Бином,
2012
.
-

420 c.

5.

Редько, В.Н.; Бассараб, И.А. Базы данных и информационные системы;
Знание,
2011
.

-

602

c
.

6.

Постолит, Анатолий Visual Studio .NET: разработка приложений баз
данных; СПб: БХВ,
2009
.
-

544 c.

7.

Хаббард, Дж. Автоматизированное проектирование баз данных; М.:
Мир
,
2011
.
-

453

c.

8.

ГОСТ 34.601
-
90. Автоматизированные системы. Стадии создания.


9.

Грекул В. Курс «Проектирование информационных систем».
URL:
http://www.intuit.ru/studies/courses/2195/55/info
.

10.


Зеленков Ю. А. В
ведение в базы данных. Учебник.
URL
:
http
://
www
.
mstu
.
edu
.
ru
/
s
tudy
/
materials
/
zelenkov
/
ch
_5_1.
html

11.


Карпова И. П. Проектирование реляционных баз данных.
Методические указания к курсовому проектированию по курсу "Базы
данных".
URL
:
http
://
rema
44.
ru
/
resurs
/
study
/
dbprj
/
dbprj
.
html
.

12.


Харрингтон Д. Проектирование реляционных баз данных.

Перевод с
англ. М. Лори, 2006г., 240 с
.

13.


Алексеева О.Г. Методические указания по экономическому
обоснованию выпускных квалификационных работ бакалавров:
методические указания.
СПб.: Изд
-
во СПбГЭТУ “ЛЭТИ”, 2013, 17 с.

109


14.


Гелмерс

Скотт

А
.
Microsoft Visio 2010
.
Шаг за шагом. М.: ЭКОМ
Паблишерс, 2011.
-

576с.




Приложенные файлы

  • pdf 7775586
    Размер файла: 2 MB Загрузок: 0

Добавить комментарий