Проектирование информационной системы «Деятельность рекламного агентства»

1. Проектирование ИС: общие понятия

2. Описание бизнес-процессов в BP-Win

2.1 IDEF0

2.2 IDEF3

2.3 DFD

3. ER-Win

4. Rational Rose

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

4.2 Диаграмма состояний

4.3 Диаграмма деятельности

4.4 Диаграммы взаимодействий

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

4.6 Проектирование структуры web-сайта

4.7 Визуальное представление web-сайта Заключение Список литературы

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

— применение на практике знаний, полученных в процессе изучения курса «Проектирование информационных систем»;

— получение практических навыков создания ИС, основанных на БД.

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

— приобретение навыков использования CASE-средств проектирования ИС.

1. Проектирование ИС: общие понятия

Проектирование — процесс преобразования входной информации об объекте проектирования в проект ИС, т. е. процесс проектирование сводится к последовательной формализации проектных решений на различных стадиях ЖЦ ИС.

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

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

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

Этапы проектирования ИС:

1. Планирование и анализ требований (предпроектная стадия) — системный анализ

2. Включает ь Исследование и анализ существующей ИС ь Определение требований к создаваемой ИС ь Оформление технико-экономического обоснования ь Оформление технического задания на разработку ИС

3. Проектирование (техническое проектирование или логическое проектирование)

4. Включает ь Разработку в соответствии со сформулированными требованиями функциональной и системной архитектуры ь Оформление технического проекта Последовательность и содержание этих этапов предписываются [ГОСТ 34.601−90. Автоматизированные системы. Стадии создания.], следующим образом:

1. Формирование требований к ИС.

1.1. Обследование объекта автоматизации и обоснование необходимости (целесообразности) создания ИС.

1.2. Формирование требований заказчика к ИС (определение целей).

1.3. Оформление отчета о выполненной работе и заявки на разработку ИС (тактико-технического задания)

2. Разработка концепции ИС.

2.1. Изучение объекта

2.2. Проведение необходимых научно-исследовательских работ

2.3. Разработка вариантов концепции ИС и выбор концепции, наиболее полно удовлетворяющего требованиям заказчика

2.4. Оформление отчета о выполненной работе

3. Техническое задание

Разработка, согласование и утверждение ТЗ на создание ИС

4. Эскизный проект

4.1. Разработка предварительных проектных решений по ИС и ее частям

4.2. Разработка документации на ИС и ее части

5. Технический проект

5.1. Разработка проектных решений по системе и ее частям

5.2. Разработка документации на ИС и ее части

5.3. Разработка и оформление документации на поставку изделий для комплектования ИС и/или технических требований на их разработку

5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации.

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

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

6. Внедрение (тестирование, опытная эксплуатация)

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

8. Эксплуатация (сопровождение, модернизация)

9. Включает ь Сбор информации о функционировании ИС ь Исправление ошибок и недоработок ь Оформление требований к модернизации

Подходы к проектированию ИС:

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

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

2. Описание бизнес процессов в BP-Win

2.1 IDEF0

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

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

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

Общая структура декомпоций IDEF0 для рекламного агентства

IDEF0

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

Фрагмент такой диаграммы рекламного агентства

Презентационные диаграммы (For Exposition Only diagrams — FEO diagrams) часто включают в модели, чтобы проиллюстрировать другие точки зрения или детали, выходящие за рамки традиционного синтаксиса IDEF0. Диаграммы FEO допускают нарушение любых правил построения диаграмм IDEF0 в целях выделения важных с точки зрения аналитика частей модели. Естественно, если диаграмма FEO включена в модель исключительно для отображения другой точки зрения на систему, она, скорее всего, внешне будет выглядеть как обыкновенная IDEF0-диаграмма, удовлетворяя всем ограничениям IDEF0.

Пример диаграммы декомпозиции А1, А2, А3, А4 для рекламного агентства

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

Стрелками входа для «заключения договоров» являются звонки клиентов и документация. Стрелками управления служат законодательство и антиплагиат. Стрелками механизма выступают директор и сотрудники рекламного агентства. Стрелка выхода — заказ клиента.

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

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

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

Диаграммы декомпозиции А11, А12, А13, А14

Диаграммы декомпозиции А21, А22, А23, А24

Диаграммы декомпозиции А31, А32

Диаграммы декомпозиции А41, А42, А43, А44

2.2 IDEF3

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

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

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

Основой модели является сценарий бизнес процесса. Единицы работы Unit of Work (UOW), также называемые работами (activity), являются центральными компонентами модели.

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

Соединения (перекрестки Junction (J)). Завершение одного действия может инициализировать выполнение сразу нескольких действий или наоборот, определенное действие может требовать завершения нескольких других действий для начала своего выполнения. Соединения разбивают или соединяют внутренние потоки и используются для описания ветвления процессов. Все перекрестки на диаграмме нумеруются, каждый номер имеет префекс J и порядковый номер (J1, J2)

? Разворачивающие соединения используются для разбиения потока

? Сворачивающие соединения объединяют потоки

Типы соединений

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

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

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

IDEF3 диаграмма для рекламного агентства

2.3 DFD

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

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

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

ь внешние сущности (внешние ссылки) external references;

ь системы/подсистемы (функции обработки информации, работы);

ь процессы;

ь накопители данных, хранилища data store (таблицы для хранения информации);

ь потоки данных (стрелки) arrows — документы, объекты, сотрудники или отделы, которые участвуют в обработке информации

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

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

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

Создание диаграммы потоков данных

DFD-Диаграммы для рекламного агентства

3. ER-Win

ER-win для проектирования реляционных баз данных

Модель сущность-связь (ER-модель) (англ. entity-relationship model, ERM) — модель данных, позволяющая описывать концептуальные схемы предметной области.

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

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

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

При создании реальных моделей данных количество сущностей и атрибутов может исчисляться сотнями. Для более удобной работы с большими моделями в ERwin предусмотрены подмножества модели (Subject Area), в котором можно включать тематические общие сущности. Одна и также сущность может входить в несколько Subject Area. Все изменения, созданные в одной Subject Area автоматически отображаются в общей модели. Каждая из Subject Area может соответствовать определенной задачи: финансовой, производственной и т. д.

Физическая модель

Логическая модель

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

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

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

Схема БД на основе диаграммы в MS Access

4. Rational Rose

CASE средство Rational Rose фирмы (Rational Software Corporation) является одним из наиболее мощных инструментариев анализа и проектирования объектно-ориентированных систем. Реализует генерацию кодов программ для С++, Visual C++, VB, Java, Power Builder. Базируется на UML.

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

Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь вариант использования служит для описания сервисов, которые система предоставляет актеру. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой. Каждый вариант использования — это потенциальное требование к системе, и пока оно не выявлено, невозможно запланировать его реализацию. Use case редактор используется для построения.

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

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

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

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

4.2 Диаграмма состояний

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

Диаграмма состояний для оформления заказа на рекламу

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

Деятельность (activity) — это поведение, реализуемое объектом, пока он находится в данном состоянии. Деятельность изображают внутри самого состояния; ее обозначению должно предшествовать слово do (делать) и двоеточие.

Входное действие (entry action) — это поведение, которое выполняется, когда объект переходит в данное состояние. Входное действие также показывают внутри состояния, его обозначению предшествуют слово entry (вход) и двоеточие.

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

Переходом (transition) называется перемещение объекта из одного состояния в другое. На диаграмме все переходы изображают в виде стрелки, начинающейся на первоначальном состоянии и заканчивающейся последующим. Переходы могут быть рефлексивными. Объект может перейти в то же состояние, в котором он в настоящий момент находится. Рефлексивные переходы изображают в виде стрелки, начинающейся и завершающейся на одном и том же состоянии Сторожевое условие (guard condition) представляет собой некоторое булевское выражение. Если сторожевое условие принимает значение «истина», то соответствующий переход срабатывает и объект переходит в новое состояние. Если сторожевое условие принимает значение «ложь», то переход не может срабатывать, и при отсутствии других переходов объект не может перейти в другое состояние по данному переходу.

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

Составное состояние (composite state) — это такое сложное состояние, которое состоит из вложенных в него состояний.

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

4.3 Диаграмма деятельности (Activity diagram)

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

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

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

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

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

4.4 Диаграммы взаимодействия

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

Диаграммы последовательности действий отображают взаимодействие объектов, упорядоченное по времени. Диаграммы последовательности обычно соответствуют реализации прецедентов в логическом представлении системы. На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии. Эта вертикальная линия называется линией жизни (lifeline) объекта или временной линией (timeline). Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия. Линия жизни служит для обозначения периода времени, в течении которого объект существует в системе и следовательно может потенциально участвовать во всех ее взаимодействиях. В процессе функционирования объектно-ориентированных систем одни объекты могут находиться в активном состоянии, непосредственно выполняя определенные действия или в состоянии пассивного ожидания сообщений от других объектов. Чтобы явно выделить подобную активность объектов применяется специальное понятие, получившее название фокус управления. Фокус управления изображается в виде вытянутого узкого прямоугольника.

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

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

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

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

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

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

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

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

если всё правильно, то он нажимает подтверждение и расплачивается карточкой. Если есть ошибка, то выполняется поток ошибок Е1.

клиент вводит свой PIN-код.

устройство дает подтверждение, в случае отсутствия подверждения, выполняется альтернативный поток событий А1.

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

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

клиент получает квитанцию и чек.

прецедент завершается.

Альтернативный поток событий А1.

1. устройство не дает подтверждения по вводу PIN-кода.

2. менеджер сообщает клиенту об ошибке.

3. прецедент завершается.

Поток ошибок Е1 — ошибка в заказе.

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

2. менеджер проверяет информацию полученную от клиента.

3. менеджер производит корректировку.

4. исправленный чек (квитанция) или заказ предоставляются клиенту на рассмотрение.

5. прецедент завершается.

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

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

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

Атрибут — это элемент информации, связанный с классом.

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

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

Ассоциации (association) — отношения между экземплярами классов.

Стрелки — навигации. Могут быть однонаправленные и двунаправленные.

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

Агрегации (aggregations) представляют собой более тесную форму ассоциации. Агрегация — это связь между целым и его частью.

Стереотипы — это механизм, позволяющий разделять классы на категории. В языке UML основными стереотипами являются: Boundary (граница), Entity (сущность) и Control (управление).

Граничные классы (boundary classes) — это классы, которые расположены на границе системы и окружающей среды. Они включают все формы, отчеты, интерфейсы с аппаратурой (такой, как принтеры или сканеры) и интерфейсы с другими системами.

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

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

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

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

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

Пример диаграммы классов для рекламного агентства

Генерация кода диаграммы классов на языке Visual Basic

CREATE TABLE T₁₄ (

сотрН INTEGER NOT NULL,

заказН INTEGER NOT NULL,

CONSTRAINT PK_T_1446 PRIMARY KEY (сотрН, заказН)

);

CREATE INDEX TC_T_14 114 ON T₁₄ (сотрН);

CREATE INDEX TC_T_14 115 ON T₁₄ (заказН);

CREATE TABLE T_сотрудники (

сотрН INTEGER NOT NULL,

фамилияСотр VARCHAR (255) NOT NULL,

имяСотр VARCHAR (255) NOT NULL,

отчествоСотр VARCHAR (255) NOT NULL,

телефонСотр INTEGER NOT NULL,

паспортСотр INTEGER NOT NULL,

кодДолжности INTEGER NOT NULL,

CONSTRAINT PK_T_сотрудники40 PRIMARY KEY (сотрН)

);

CREATE INDEX TC_T_сотрудники127 ON T_сотрудники (кодДолжности);

CREATE TABLE T_должности (

кодДолжности INTEGER NOT NULL,

должностьСотр VARCHAR (255) NOT NULL,

сотрН INTEGER,

CONSTRAINT PK_T_должности42 PRIMARY KEY (кодДолжности)

);

CREATE INDEX TC_T_должности129 ON T_должности (сотрН);

CREATE TABLE T_прайслист (

кодУслуги INTEGER NOT NULL,

названиеУслуги VARCHAR (255) NOT NULL,

ценаУслуги DOUBLE PRECISION NOT NULL,

кодПродукции INTEGER NOT NULL,

CONSTRAINT PK_T_прайслист43 PRIMARY KEY (кодУслуги)

);

CREATE INDEX TC_T_прайслист130 ON T_прайслист (кодПродукции);

CREATE TABLE T_заказы (

заказН INTEGER NOT NULL,

датаЗ DATE NOT NULL,

датаВыполнЗаказа DATE NOT NULL,

датаВыдачиЗаказа DATE NOT NULL,

получен SMALLINT NOT NULL,

стоимость DOUBLE PRECISION NOT NULL,

T_клиент_ID INTEGER NOT NULL,

CONSTRAINT PK_T_заказы41 PRIMARY KEY (заказН)

);

CREATE INDEX TC_T_заказы128 ON T_заказы (T_клиент_ID);

CREATE TABLE T_виды_услуг (

кодПродукции INTEGER NOT NULL,

назвВидаУслуг VARCHAR (255) NOT NULL,

кодУслуги INTEGER,

T_прайслист_кодУслуги INTEGER NOT NULL,

CONSTRAINT PK_T_виды_услуг44 PRIMARY KEY (кодПродукции)

);

CREATE INDEX TC_T_виды_услуг131 ON T_виды_услуг (кодУслуги);

CREATE INDEX TC_T_виды_услуг132 ON T_виды_услуг (T_прайслист_кодУслуги);

CREATE TABLE T₁₆ (

заказН INTEGER NOT NULL,

кодУслуги INTEGER NOT NULL,

CONSTRAINT PK_T_1648 PRIMARY KEY (заказН, кодУслуги)

);

CREATE INDEX TC_T_16 119 ON T₁₆ (заказН);

CREATE INDEX TC_T_16 120 ON T₁₆ (кодУслуги);

CREATE TABLE T_клиент (

клиентН INTEGER NOT NULL,

фамилияКл VARCHAR (255) NOT NULL,

ИмяКл VARCHAR (255) NOT NULL,

ОтчествоКл VARCHAR (255) NOT NULL,

телефонКЛ INTEGER NOT NULL,

паспортКл INTEGER NOT NULL,

адресКл VARCHAR (255) NOT NULL,

T_клиент_ID INTEGER NOT NULL,

CONSTRAINT PK_T_клиент45 PRIMARY KEY (T_клиент_ID)

);

ALTER TABLE T_виды_услуг ADD CONSTRAINT FK_T_виды_услуг69 FOREIGN KEY (кодУслуги) REFERENCES T_прайслист (кодУслуги) ON DELETE NO ACTION ON UPDATE NO ACTION;

ALTER TABLE T_виды_услуг ADD CONSTRAINT FK_T_виды_услуг70 FOREIGN KEY (T_прайслист_кодУслуги) REFERENCES T_прайслист (кодУслуги) ON DELETE NO ACTION ON UPDATE NO ACTION;

ALTER TABLE T_заказы ADD CONSTRAINT FK_T_заказы63 FOREIGN KEY (T_клиент_ID) REFERENCES T_клиент (T_клиент_ID) ON DELETE NO ACTION ON UPDATE NO ACTION;

ALTER TABLE T₁₆ ADD CONSTRAINT FK_T_1666 FOREIGN KEY (заказН) REFERENCES T_заказы (заказН) ON DELETE NO ACTION ON UPDATE NO ACTION;

ALTER TABLE T₁₆ ADD CONSTRAINT FK_T_1667 FOREIGN KEY (кодУслуги) REFERENCES T_прайслист (кодУслуги) ON DELETE NO ACTION ON UPDATE NO ACTION;

ALTER TABLE T₁₄ ADD CONSTRAINT FK_T_1461 FOREIGN KEY (сотрН) REFERENCES T_сотрудники (сотрН) ON DELETE NO ACTION ON UPDATE NO ACTION;

ALTER TABLE T₁₄ ADD CONSTRAINT FK_T_1462 FOREIGN KEY (заказН) REFERENCES T_заказы (заказН) ON DELETE NO ACTION ON UPDATE NO ACTION;

ALTER TABLE T_сотрудники ADD CONSTRAINT FK_T_сотрудники68 FOREIGN KEY (кодДолжности) REFERENCES T_должности (кодДолжности) ON DELETE NO ACTION ON UPDATE NO ACTION;

ALTER TABLE T_прайслист ADD CONSTRAINT FK_T_прайслист73 FOREIGN KEY (кодПродукции) REFERENCES T_виды_услуг (кодПродукции) ON DELETE NO ACTION ON UPDATE NO ACTION;

ALTER TABLE T_должности ADD CONSTRAINT FK_T_должности60 FOREIGN KEY (сотрН) REFERENCES T_сотрудники (сотрН) ON DELETE NO ACTION ON UPDATE NO ACTION;

4.6 Проектирование структуры web-сайта

4.7 Визуальное представление спроектированного web-сайта

Заключение

В ходе выполнения курсовой работы были достигнутые поставленные цели, такие как: применение на практике знаний, полученных в процессе изучения курса «Проектирование информационных систем» и получение практических навыков создания информационных систем, основанных на БД. Так же, я считаю, с успехом были освоены программы «Process Modeler», «ERwin Data Modeler» и «IBM Rational rose».

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

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

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

1. Н. В. Барклаевская, Методические указания к выполнению лабораторных работ, СПб, 2006.