На  Рис. 8 представлена декомпозиция в нотации DFD «Работа Спортивно-Оздоровительного Комплекса», описывающая всю деятельность центра.

    Рис. 8 - Декомпозиции в нотации DFD «Работа Спортивно-Оздоровительного Комплекса».

    Все работы, представленные на диаграмме, выполняются «Персоналом» в соответствие с должностными инструкциями.

 

3.3 Создание модели базы данных с помощью Erwin Data Modeler 4.1

 

    Для представления информационной модели данных использовалось CASE-средство ERWin. С его помощью создана логическая и физическая модель базы данных, представленная ниже (Рис. 9, 10).

    

    Рис. 9 - Модель данных в нотации IDEF1X (логический уровень)

    Рис. 10 - Модель данных в нотации IDEF1X (физический уровень) 

    База  данных представлена в виде сущностей, их атрибутов и связей между ними. Каждая сущность представляет множество  подобных объектов, называемых экземплярами. Каждый экземпляр индивидуален и  должен отличаться от всех остальных. Атрибут выражает определенное свойство объекта. С точки зрения физической модели базы данных сущности соответствует  таблица (например, «Клиент», «Абонемент»), экземпляру сущности – строка в таблице, а атрибуту – колонка таблицы. В результате проектирования было выделено семь сущностей.

    Связь на диаграмме отображает логическую зависимость одной сущности от другой. В IDEF1X различают зависимые и независимые  сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается  между независимой (родительский конец  связи) и зависимой (дочерний конец  связи) сущностями. Экземпляр зависимой  сущности определяется только через отношение к родительской сущности. Зависимая сущность изображается на диаграмме прямоугольником со скругленными углами.

    На  нашей диаграмме зависимыми сущностями являются: «Договор», «Абонемент» и «Квитанция об оплате», для которых родительскими сущностями являются сущности «Клиент», «Инструкторы и «Прайс-лист».

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

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

    Например, на рис. 9 сущность «Договор» однозначно идентифицирует первичный ключ «ФИО Клиента  (FK)».

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

    Примером  такой миграции является отношение  сущностей «Клиент» и «Абонемент», «Клиент» и «Договор»,  «Квитанция об оплате» и «Абонемент» и т.д.

 

3.4 Проектирование ИС в объектно–ориентированном представлении

 

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

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

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

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

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

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

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

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

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

    Рис. 13 – Диаграмма взаимодействия прецедента «Оформить абонемент».

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

    Рис. 15 – Диаграмма взаимодействия прецедента «Выписать клиента». 

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

   На  рисунке 16 представлена диаграмма состояний.   
 
 

    Рис. 16 – Диаграмма состояний абонемента.

 

3.5 Создания пользовательского интерфейса

 

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

1. Естественность (интуитивность). Работа с системой не должна вызывать у пользователя сложностей в поиске необходимых элементов интерфейса для управления процессом решения поставленной задачи.
2. Непротиворечивость. Если в процессе работы с системой пользователем были использованы некоторые приемы работы с некоторой частью системы, то в другой части системы приемы работы должны быть идентичны. Также работа с системой через интерфейс должна соответствовать установленным, привычным нормам (например, использование клавиши Enter).
3. Неизбыточность. Это означает, что пользователь должен вводить только минимальную информацию для работы или управления системой. Например, пользователь не должен вводить незначимые цифры (00010 вместо 10). Аналогично, нельзя требовать от пользователя ввести информацию, которая была предварительно введена или которая может быть автоматически получена из системы. Желательно использовать значения по умолчанию где только возможно, чтобы минимизировать процесс ввода информации.
4. Непосредственный доступ к системе помощи. В процессе работы необходимо, чтобы система обеспечивала пользователя необходимыми инструкциями. Система помощи отвечает трем основным аспектам - качество и количество обеспечиваемых команд; характер сообщений об ошибках и подтверждения того, что система делает. Сообщения об ошибках должны быть полезны и понятны пользователю.

 

  Формы – основной элемент интерфейса. Назначение форм – удобный ввод и просмотр данных, состояния, сообщений  автоматизированной системы.

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

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

  

    Рис. 17 – Справочник «Договоры». 

    Рис. 18 – Справочник «Абонементы». 

    Рис. 19 – Справочник «Клиенты».

 

    Рис. 20 – Интерфейс формы «Посещения».

 

Заключение

 

    На  примере данной курсовой работы продемонстрировано проектирование информационной системы.

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

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

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

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

    Для выполнения данной курсовой работы в качестве инструмента был выбран программный продукт BPwin. Он позиционируется для использования проектировщиками, аналитиками, разработчиками. Bpwin – это CASE-средство визуального проектирования информационных систем, позволяющее моделировать бизнес-процессы, реализующее метод IDEF0. Текущая версия BPwin поддерживает также диаграммы потоков данных и потоков работ.

    На  этапе моделирования подсистемы были использованы нотации SADT (Structured Analysis and Design Technique) и DFD (Data Flow Diagrams), позволяющие  наиболее адекватно отобразить логику предметной области и легко воспринимающиеся для анализа. Диаграммы потоков  данных и диаграммы "сущность-связь" — наиболее часто используемые в CASE-средствах виды моделей.

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

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

    Для объектно-ориентированного подхода было использовано средство визуального моделирования объектно-ориентированных информационных систем Rational Rose.

    В рамках этой методологии были построены:

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

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

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

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

 

Список  использованной литературы 

1. Долгина, Т. В. Проектирование информационных систем [Текст]: методические указания по выполнению лабораторных работ – Кемерово: КемИ (филиал) «РГТЭУ», 2006. – 80 с.
2. Черемных, С. В. Моделирование и анализ систем. IDEF-технологии [Текст]: практикум / С. В. Черемных, И. О. Семенов, B. C. Ручкин. – М: Финансы и статистика, 2006. – 192 с. – ISBN: 5-279-02564-Х
3. Смирнова, Г.Н. Проектирование экономических информационных систем [Текст] / Г. Н. Смирнова, А. А. Сорокин, Ю. Ф. Тельнов – М.: Финансы и статистика, 2001. – 512 с. – ISBN: 5-279-02295-0
4. Крутов В. Русанов Е. Новые возможности моделирования и анализа бизнеса // Открытые системы.- 2004.- №12.- С.42-45.
5. Малков О.Б., Белимова Е.В. Проектирование баз данных с использованием CASE-технологии: Методические указания. Омск, 2003. - 48с.
6. Проектирование экономических информационных систем: Учебник / Г.Н. Смирнова, А.А. Сорокин, Ю.Ф. Тельнов; Под ред. Ю.Ф. Тельнова. – М.: Финансы и статистика, 2001. – 512с.
7. http://www.intuit.ru – Интернет университет информационных технологий.
8. Маклаков С.В. Bpwin и Erwin. CASE-средства разработки информационных систем. – М.: Диалог-МИФИ, 2001. – 304 с.
9. Вендров А.М. Проектирование программного обеспечения экономических информационных систем:. Учебник. – М.: Финансы и статистика, 2000. – 352 с.
10. Калянов Г. Н. CASE-технологии. Консалтинг в автоматизации бизнес процессов. –3-е изд. – М.: Горячая линия – Телеком, 2002. – 320с.
11. Голицина О.Л., Максимов Н.В., Попов И.И. Базы данных: Учебное пособие. – М.: ФОРУМ: ИНФРА-М, 2003. – 352 с.