Проект приложения базы данных для предметной области «Кинотеатр»

     Порядок контроля и приемки  системы  
ГОСТ 34.602-89 п 2.8

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

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

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

     Требования  к составу и  содержанию работ  по подготовке объекта автоматизации к вводу системы в действие  
ГОСТ 34.602-89 п 2.9

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

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

     Отсутствие сервера для установки АИС не может являться основанием в отказе подписания Акта приема-передачи АИС в промышленную эксплуатацию.

     Требования  к документированию ГОСТ 34.602-89 п 2.10

     По  окончанию второго этапа Разработчик передает Заказчику следующую документацию:

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

     Иная  документация Заказчику не предоставляется. Инструкции предоставляются как в печатном, так и в электронном виде. Инструкции в печатном виде предоставляется в одном экземпляре.

     Источники разработки. ГОСТ 34.602-89 п 2.11

   При разработке АИС должны использоваться следующие законодательные и нормативные правовые акты:

• Указ Президента РФ от 06.03.1997 г. № 188 "Об утверждении перечня сведений конфиденциального характера";
• Указ Президента РФ от 30.11.1995 г. № 1203 "Об утверждении перечня сведений, отнесенных к государственной тайне";
• ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании автоматизированных систем»;
• ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания»;
• ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы»;
• ГОСТ 34.603-92 «Виды испытаний автоматизированных систем»;
• РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов»;

 
 

   2. Модель IDEF0

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

  Построение  модели информационной системы начинается с описания функционирования предприятия (системы) в целом в виде контекстной  диаграммы. В приложении 1 представлена контекстная диаграмма АИС «Кинотеатр». Как  видно из диаграммы в Приложении рис.1,  взаимодействие системы с окружающей средой описывается в терминах входа (на диаграмме в Приложении рис.1 это «Досуг») выхода (основной результат процесса – «Просмотр фильма»), управления («Правила поведения в кинотеатре», «План кинотеатра», «Правила работы кинотеатра», «Реклама», «Афиша») и механизмов (“Зритель” – это ресурс, необходимые для процесса функционирования кинотеатра).

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

     Весь  процесс “Кинотеатра” разбивается на 4:

1. выбор кинотеатра (здесь клиент(зритель) выбирает кинотеатр в который он хочет пойти, путем просмотра реклам и афиш) раскрытая декомпозиция представлена в Приложении рис.3;
2. выбор фильма;       
3. покупка билета (непосредственный контакт с кассиром при котором происходит «Выбор времени сеанса» и «Выбор места в зале») раскрытая декомпозиция представлена в Приложении рис.4;
4. просмотр фильма (осуществляется после прохода через контроль и занятия места согласно купленному билету) раскрытая декомпозиция представлена в Приложении рис.5.

   

     3. DFD модель

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

     В DFD диаграммах преобладают имена  существительные.  

Функциональные  блоки

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

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

     Внешние сущности

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

     Стрелки (потоки данных)

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

     Хранение  данных

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

     Ветвление и объединение

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

     Стрелки могут соединяться  между собой.

     Диаграмму DFD можно строить с использованием подхода анализа при проектировании, применяющемся в IDEF0.

     DFD модель изображена на рис.6-9 в Приложении. Всего имеется 4 функциональных блока:.

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

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

     Кассир  осуществляет продажу билетов при  этом он вносит информацию о проданном билете.

     4. Модель IDEF1X

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

     К основным понятиям методики моделирования IDEF1X относятся следующие:

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

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

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

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

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

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

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

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

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

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