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

Содержание

1. Введение

2. Инструменты разработки информационной системы

2.1 BPwin

2.2 ERWin

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

4. Функциональная модель бизнес-процесса

4.1 Моделирование в IDEF0

4.2 Диаграммы информационной системы “Видеопрокат” в нотации IDEF0

4.3 Моделирование в DFD

4.4 Диаграммы информационной системы “Видеопрокат” в нотации DFD

5. Модели данных информационной системы

5.1 IDEF1X

5.2 Концептуальная модель данных

5.3 Логическая модель данных

5.4 Физическая модель данных

6. Проектирование с использованием UML

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

7. Заключение

8. Список литературы

1. Введение

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

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

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

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

Задачами курсового проекта являются:

· Разработка видеопроката в нотации IDEF0 инотации DFD

· Моделирование данных видеопроката в IDEF1X

· Проектирования с использованием UML

2. Инструменты разработки информационной системы

2.1 BPwin

Для проведения анализа и реорганизации бизнес-процессов Logic Works предлагает CASE-средство верхнего уровня - BPwin, поддерживающее методологии IDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram). Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей - того, к чему нужно стремиться (модель TO-BE). Методология IDEF0 предписывает построение иерархической системы диаграмм - единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. После каждого сеанса декомпозиции проводится сеанс экспертизы, каждая диаграмма проверяется экспертами предметной области, представителями заказчика, людьми, непосредственно участвующими в бизнес-процессе. Такая технология создания модели позволяет построить модель, адекватную предметной области на всех уровнях абстрагирования. Если в процессе моделирования нужно осветить специфические стороны технологии предприятия, BPwin позволяет переключиться на любой ветви модели на нотацию IDEF3 или DFD и создать смешанную модель. Нотация DFD включает такие понятия, как внешняя ссылка и хранилище данных, что делает ее более удобной (по сравнению с IDEF0) для моделирования документооборота. Методология IDEF3 включает элемент "перекресток", что позволяет описать логику взаимодействия компонентов системы. Bpwin основан на методологии IDEF.

Для BPwin 4.0 нужно отметить существенно улучшенный интерфейс, если сравнивать с предыдущими версиями. Нет проблем со шрифтами, с изменением размеров объектов на диаграмме, что раньше в некоторых случаях могло привести к тому, что диаграмма “плыла”. Кроме проводника модели, улучшены также и словари объектов. Теперь все словарные объекты располагаются в радующих глаз аккуратных таблицах. Вид этих таблиц можно настраивать так, как удобно разработчику, содержание словарей можно печатать, экспортировать, импортировать, также можно генерировать отчеты по содержанию словарей. Можно поддерживать словари для следующих объектов: работы, стрелки, хранилища данных, внешние ссылки, перекрестки, объекты ссылок, атрибуты, центры затрат, сущности, ресурсы, роли, группы ролей, свойства, определяемые пользователем (UDP).

Данный продукт тесно интегрирован с инструментальным средством для моделирования БД - ERWin.

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

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

Официальная версия программы относительно недешева

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

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

2.2 ERWin

Пакет ERWin - средство, используемое при моделировании и создании баз данных произвольной сложности на основе диаграмм «сущность - связь». Продукт компании Computer Associates. ERWin это средство концептуального моделирования БД. Используется при моделировании и создании баз данных произвольной сложности на основе диаграмм «сущность ? связь». В настоящее время ERWin является наиболее популярным пакетом моделирования данных благодаря поддержке широкого спектра СУБД самых различных классов.

Возможности ERWin:

· поддерживает методологию структурного моделирования SADT и следующие нотации: стандартную нотацию IDEF1x для ER-диаграмм моделей данных, нотацию IE и специальную нотацию, предназначенную для проектирования хранилищ данных - Dimensional;

· поддерживается прямое (создание БД на основе модели) и обратное (генерация модели по имеющейся базе данных) проектирование для 20 типов СУБД: настольные, реляционные и специализированные СУБД, предназначенные для создания хранилищ данных;

· интегрирован линейкой продуктов Computer Associates для поддержки всех стадий разработки ИС, CASE-средствами Oracle Designer, Rational Rose, средствами разработки и др.;

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

· возможна совместная работа группы проектировщиков с одними и теми же моделями (с помощью AllFusion Model Manager);

· позволяет переносить структуру БД (не сами данные!) из СУБД одного типа СУБД в другой;

· позволяет документировать структуру БД.

Достоинства:

· распространенность;

· распространены методические рекомендации по работе;

· техподдержка;

· ошибки программы известны и описаны.

Недостатки:

· нельзя создавать стандартные операции;

· репрезентативные свойства низки;

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

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

· жесткая методология;

· требуется дополнительное обучение в понимании самой методологии;

· не очень удачные генераторы проектной документации;

· официальная версия программы относительно недешева.

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

Задача.

Необходимо спроектировать программное и информационное обеспечение системы.

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

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

Назначение системы.

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

· быстрый поиск видео по названию, жанру, режиссёру и т.п.

· постоянные клиенты могут пополнять коллекцию кассет.

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

· id клиента ;

· ФИО;

· телефон;

· адрес;

· паспортные данные;

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

· id кассеты;

· название фильма;

· режиссёр;

· жанр;

· в наличии.

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

· id клиента;

· id кассеты

· количество дней;

В создаваемом информационной системе могут работать группы пользователей:

· сотрудники;

· клиенты.

Сотрудники благодаря данному программному продукту могут решать следующие задачи:

· добавлять данные о кассетах;

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

· принимать возвращаемые кассеты и оплату проката;

· сдавать выручку инкассатору;

· добавлять информацию о клиентах

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

· осуществлять поиск видео;

· просмотр своих данных;

4. Функциональная модель бизнес-процесса

4.1 Моделирование в IDEF0

IDEF0 -- это метод описания системы в целом как множества взаимозависимых функций (действий).

Функции системы исследуются независимо от объектов, обеспечивающих их выполнения. Такая сугубо «функциональная» точка зрения позволяет четко отделить аспекты назначения системы от вопросов ее реализации.

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

Нотация IDEF0

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

IDEF0 определяет два графических объекта:

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

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

Функция обрабатывает входные объекты и преобразует их в выходные. Функциональный блок обозначается так:

Рис 1. Функциональный блок

«Формирование отчета» -- наименование функции, «1» -- номер функции. Наименование функции должно характеризовать процесс и состоять из глагола или отглагольного существительного с дополнением. Наименование должно соответствовать выбранной точки зрения моделирования (см.ниже). Для функционального блока обязательно должно быть указано наименование.

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

На IDEF0-диаграммах с помощью стрелок можно показывать до четырех типов объектов:

Вход (Input, I).

Управление, или контроль (Control, C).

Выход (Output, O).

Исполняющий механизм (Mechanism, M) -- то, что используется для собственно выполнения процесса, но остается неизменным (либо изменения незначимы и являются побочным результатом).

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



Рис 2. Функциональный блок и разные типы стрелок

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

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

Описание стрелок

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

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

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

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

Соединение блоков

В IDEF0 существует 5 основных типов соединения функциональных блоков.

Выход-вход.

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

Рис 3. Выход-вход

Выход-управление.

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



Рис 4. Выход-управление

Выход-механизм исполнения.

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

Рис 5. Выход-механизм исполнения

Выход-обратная связь на вход.

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

Рис 6. Выход-обратная связь на вход

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

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

Рис 7. Выход-обратная связь на управление

Соединение и разъединение стрелок

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

Рис 8. Соединение и разъединение стрелок

Нумерация блоков и диаграмм.

Все блоки нумеруются. Номер имеет вид <префикс><цифра>. Префикс представляет совокупность некоторой строки (обычно символ “A”) и номера родительского блока. Для блоков первого уровня детализации номер родительского не указывается. Контекстная функция обозначается как A0, декомпозирующие ее блоки -- A1, A2, A3,... Далее, блок A1 может декомпозироваться на A1.1, A1.2,...; A1.1 -- на A1.1.1, A1.1.2,... Точки обычно не ставятся, поскольку на грамотно построенной диаграмме не бывает больше 6-7 блоков. Т.е.: A0, A1, A11, A111,...

Туннелирование

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

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

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

Другие типы диаграмм IDEF0

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

Презентационная диаграмма (For Exposition Only, FEO) допускает любые нарушения синтаксиса IDEF0. Фактически, это любая иллюстрацию. Обычно такие диаграммы используются для более полного описания функциональных блоков и их совокупностей.

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

Рис. 9. Дерево модели

Рис 10. Дерево диаграмм видеопроката.



Рис. 11. Контекстная диаграмма процесса



Рис. 12. Диаграмма 2-го уровня - декомпозиция контекстной диаграммы



Рис. 13. Диаграмма 3-го уровня - диаграмма декомпозиции блока А1



Рис. 14. Диаграмма 3-го уровня - диаграмма декомпозиции блока А2



Рис. 15. Диаграмма 3-го уровня - диаграмма декомпозиции блока А3

Рис. 16. Диаграмма 3-го уровня - диаграмма декомпозиции блока А4



Рис. 17. Диаграмма 3-го уровня - диаграмма декомпозиции блока А5

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

4.3 Моделирование в DFD

Аналогично IDEF0, диаграммы потоков данных (Data Flow Diagrams -- DFD) позволяют моделировать систему как набор функций (действий, операций и т.п.), соединенных стрелками.

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

Имеется два основных варианта DFD: метод Гейна-Сарсона (Gane-Sarson) и метод Йордана-Де Марко (Yourdon-DeMarco). Нотации этих методов различаются.

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

Основными элементами DFD являются:

внешние сущности;

системы и подсистемы;

процессы;

накопители (хранилища) данных (data store);

потоки данных.

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

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

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

Наименование системы и подсистемы представляет собой существительное или некоторое предложение с подлежащим.

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

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

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

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

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

В зависимости от нотации, элементы DFD могут обозначаться по-разному.

Элемент	Нотация Гейна-Сарсона	Нотация Йордана-Де Марко
Внешняя сущность
Процесс
Накопитель данных
Поток данных

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

Потоки могут быть двунаправленными:

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

В самом общем случае, порядок построения иерархии DFD следующий:

Создание контекстной диаграммы; обычно для простой ИС строится одна диаграмма со звездообразной топологией: центр звезды -- система, углы -- внешние сущности.

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

Завершение детализации. Детализация процесса не выполняется в следующих случаях:

небольшое число входных и выходных потоков данных (2-3 потока);

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

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

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

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

Внешние сущности и накопители данных также обычно нумеруются. Номер накопителя данных состоит из префикса D (Data store) и уникального порядкового номера накопителя во всей модели DFD. Номер внешней сущности состоит из префикса E (External entity) и ее уникального порядкового номера в модели.

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

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

размещать на одной диаграмме 3-7 процессов (меньше 3 -- малоосмысленная детализация, больше 7 -- излишне сложная схема);

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

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

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

При построении диаграмм DFD часто удобно придерживаться такой последовательности действий:

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

Выявить все важные внешние объекты.

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

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

Изучить предварительную КД, внести требуемые изменения.

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

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

Проверить корректность DFD первого уровня.

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

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

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

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

Пример использования DFD

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

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

С учетом указанных сведений, контекстная диаграмма может иметь вид:

Рис 18. Пример контекстной диаграммы

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

Рис 19. Пример DFD диаграммы

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

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

4.4 Диаграммы информационной системы “Видеопрокат” в нотации DFD

Рис. 20. Контекстная DFD диаграмма



Рис. 21. Диаграмма DFD 2-го уровня



Рис. 22. Диаграмма DFD 3-го уровня - диаграмма декомпозиции блока А1



Рис. 23. Диаграмма DFD 3-го уровня - диаграмма декомпозиции блока А2



Рис. 24 Диаграмма DFD 3-го уровня - диаграмма декомпозиции блока А3



Рис. 25. Диаграмма DFD 3-го уровня - диаграмма декомпозиции блока А4



Рис. 26. Диаграмма DFD 3-го уровня - диаграмма декомпозиции блока А5

5. Модели данных информационной системы

Цель моделирования данных состоит в обеспечении разработчика ИС схемой базы данных (БД). Схема может состоять из одной или нескольких моделей данных.

Наиболее распространенным способом моделирования данных является подход с использованием диаграмм «сущность-связь» (Entity Relationship Diagrams, ERD), ориентированных на разработку реляционных БД.

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

5.1 IDEF1X

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

Основными элементами диаграмм сущность-связь являются:

сущности;

свойства сущностей (атрибуты);

отношения (связи) между сущностями.

В общем случае разработка модели по IDEF1X включает следующие шаги:

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

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

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

раскрываются нестандартные отношения (типа «многие ко многим»), определяются ключевые и наиболее важные с функциональной точки зрения атрибуты сущностей; данная информация отображается на логическом уровне модели (или, в терминах IDEF1X, "key-based view");

полностью определяются все атрибуты сущностей, все элементы модели получают непротиворечивые физические имена; получаемый в результате физический уровень модели (в терминах IDEF1X "fully attributed view") может быть отображен в РБД с точно соответствующей ему структурой.

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

Сущность

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

Отдельное свойство объекта выражает атрибут. Сущность включает определение одного и более атрибутов.

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

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

Если рассматривать эти элементы с точки зрения конечной РБД, то сущности соответствует таблица, экземпляру сущности - строка, атрибуту - колонка таблицы.

Основные свойства сущности:

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

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

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

сущность может иметь любое количество отношений с другими сущностями.

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

Пример отображения сущности "Сотрудник" на разных уровнях модели:

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

логический:

физический:

Рис. 27. Сущность на разных уровнях модели:

Более детальное рассмотрение свойств сущности требует определения понятия «связь» и дается ниже.

Атрибут

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

Экземпляр атрибута -- это значение атрибута. С позиции конечного представления в РБД атрибуту соответствует колонка таблицы.

Атрибуты бывают обязательными и необязательными. Если атрибут необязателен, то он может принимать неопределенное значение (NULL).

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

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

Необязательные атрибуты помечаются буквой “O” (optional). Например, пусть атрибут "Телефон" не является обязательным, тогда:

Рис. 28. Необязательные атрибуты

Если, кроме первичного ключа, для сущности можно указать еще несколько атрибутов (групп атрибутов), уникально определяющих экземпляр сущности, то такие атрибуты называются альтернативными ключами. Альтернативные ключи помечаются аббревиатурой AK (от alternate key):

Основные свойства атрибута:

принадлежит только одной сущности;

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

первичный ключ не может принимать неопределенные значения;

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

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

Связь (отношение)

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

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

На уровне конечной БД связи соответствует ограничение целостности.

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

В зависимости от характера связи, соединяющей сущности, в IDEF1X выделяются зависимые и независимые сущности. С этой точки зрения связи делятся на идентифицирующие и неидентифицирующие.

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

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

В случае связи «один ко многим» экземпляру родительской сущности соответствует произвольное, в том числе нулевое, количество экземпляров потомков, а экземпляр сущности-потомка ассоциирован с одним экземпляром родительской сущности:

При использовании отношения «один ко многим» может устанавливаться идентифицирующая (identifying) связь между одной независимой (родительской) и одной зависимой (дочерней) сущностью. Это означает, что экземпляр дочерней сущности не может существовать, если нет соответствующего ему экземпляра родительской сущности. Это достигается путем так называемой миграции атрибутов первичного ключа родительской сущности в состав первичного ключа дочерней сущности. Первичный ключ родительской сущности становится так называемым внешним ключом (foreign key) для дочерней сущности. При этом атрибуты первичного ключа родительской сущности становятся связанными с соответствующими им атрибутами первичного ключа дочерней сущности: удалением экземпляра родительской сущности приводит к принятию атрибутами внешнего ключа неопределенных значений и, соответственно, фактическому удалению тех экземпляров дочерней сущности, которые были связаны с удаленным экземпляром родительской. Действительно, внешний ключ входит в состав первичного ключа дочерней сущности и его атрибуты не могут принимать неопределенные значения без потери свойства однозначной идентифицируемости сущности.

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

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

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

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

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

Тип иерархии указывается через вид знака иерархии:

неполная
полная

Свойства наследования:

категориальная сущность может иметь только одну родовую сущность;

категориальная сущность может быть родовой в другом категориальном отношении;

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

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

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

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

дискриминатор в полной иерархии не может принимать неопределенное значение;

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

5.2 Концептуальная модель данных

Рис. 29. Концептуальная модель данных

5.3 Логическая модель данных

Рис. 30. Логическая модель данных

5.4 Физическая модель данных

Рис. 31. Физическая модель данных

6. Проектирование с использованием UML

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

В 1994 году было положено начало формированию стандартного языка для объектно-ориентированного анализа и моделирования. Данный язык получил наименование «Unified Modeling Language» (UML) -- унифицированный язык моделирования. Основными авторами языка стали Г. Буч (Booch), А. Джекобсон (Jacobson), Д. Рамбо (Rumbaugh). Каждый из них являлся автором своего объектно-ориентированного метода: Booch, OOSE (Object-Oriented Software Engineering) и OMT (Object Modeling Technique) соответственно. Поэтому UML вобрал в себя значительную часть нотации этих методов.

В 1997 году версия 1.0 языка была принята консорциумом OMG (Object Management Group) в качестве стандарта на язык объектно-ориентированного анализа и проектирования, а также бизнес-моделирования.

По состоянию на 2003 год базовой версией языка является версия 2.0 (одобрена в июне месяце).

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

Последовательность и содержание этапов при проектировании ИС в рамках объектно-ориентрованного подхода следующие:

анализ требований, или точное определение требований к ИС, во время которого определяются основные выполняемые системой действия с внешней точки зрения (обычно с точки зрения пользователей);

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

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

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

Совокупности UML-диаграмм определенного типа задают основные виды на всю архитектуру ИС:

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

вид с точки зрения проектирования (design view) описывает классы, интерфейсы и их взаимоотношения, что составляет словарь предметной области и ИС; данный вид содержит как статические (классы), так и динамические (взаимоотношения) составляющие;

вид с точки зрения процессов (process view) охватывает нити управления и процессы, т.е. описывает параллелизм и синхронизацию действий в ИС;

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

вид с точки зрения развертывания (deployment view) охватывает аппаратуру ИС и физическое размещение программных компонент ИС.

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

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

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

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

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

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

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

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



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

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

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

Рис.32. Прецедент: "Запрос на выбор кассеты клиентом"

Рис.33. Прецедент: “Получить список клиентов, которые имеют более двух кассет на руках”

Рис.34. Прецедент: “Получить новых постоянных клиентов, которых необходимо переместить из списка частных клиентов в список постоянных клиентов.”

7. Заключение

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

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

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

8. Список литературы

информационная система автоматизация данные

1.Н.В. Барклаевская «Использование ER-Win для проектирования реляционных баз данных». Методические указания к выполнению лабораторных работ, ГУАП, 2006г.

2. Маклаков С.В. Создание информационных систем с AllFusion Modeling Suite. М.: ДИАЛОГ-МИФИ, 2003

3.Федорова Д.Э., Семенов Ю.Д., Чижик К.Н. CASE-технологии. - М.: Горячая линия Телеком, Радио и связь, 2005. - 160 с.

Размещено на Allbest.ru